IEEE Spectrum December, 2008 - 37

remarkable if this ploy had not become more common.
A number of such strategies evolved through innocent experimentation. Take peer-to-peer file sharing-
a common way to exchange movies over the Internet,
one that accounts for a large portion of all traffic. It
involves downloading a file from several peers at once.
This parallel scheme, sometimes known as swarming, had become routine by 2001, built into such protocols as BitTorrent.
The networking community didn't immediately
view connecting with many machines as a circumvention of the TCP-friendliness rule. After all, each
transfer used TCP, so each data flow "correctly" got
one share of any bottleneck it encountered. But using
parallel connections to multiple machines was a new
degree of freedom that hadn't been thought of when
the rules were first written. Fairness should be defined
as a relation between people, not data flows.
Peer-to-peer file sharing exposed both of TCP's
failings. First, a file-sharing program might be active
20 times as often as your Web browser, and second, it
uses many more TCP connections, typically 5 or even
50 times as many. Peer-to-peer thus takes 100 or 1000
times as many shares of Internet bottlenecks as a
browser does.
Returning to our 100 broadband customers:
if they were just browsing the Web and exchanging e-mail, each would get nearly the full benefit of a
2 Mb/s access pipe-if 5 customers were active at a time,
they'd just squeeze into the 10Mb/s shared pipe. But if
even 20 users started continuous parallel downloading, the TCP algorithm would send everyone else's bit
rate plummeting to an anemic 20 kilobits per second-
worse than dial-up! The problem isn't the peer-to-peer
protocols; it's TCP's sharing rules.

here's a far better solution than
fighting. It would allow light browsing to go
blisteringly fast but hardly prolong heavy
downloads at all. The solution comes in
two parts. Ironically, it begins by making it easier for programmers to run TCP multiple
times-a deliberate break from TCP-friendliness.
Programmers who use this new protocol to transfer data will be able to say "behave like 12 TCP flows"
or "behave like 0.25 of a TCP flow." They set a new
parameter-a weight-so that whenever your data
comes up against others all trying to get through
the same bottleneck, you'll get, say, 12 shares, or a
quarter of a share. Remember, the network did not
set these priorities. It's the new TCP routine in your
own computer that uses these weights to control the
number of shares it takes from the network.
At this point in my argument, people generally
ask why everyone won't just declare that they each
deserve a huge weight. The answer to the question
involves a trick that gives everyone good reason to
use the weights sparingly-a trick I'll get to in a minute. But first, let's check how this scheme ensures the
lightning-fast browsing rates I just promised.

Bit rate

h y ca n ' t t h e s e rv i c e prov i de r s i m p l y u p g r a d e t h a t
stingy 10 Mb/s shared pipe? Of
course, some upgrades are necessary from time to time. But as a general approach to the problem of sharing, adding capacity is like throwing water uphill.
Imagine two competing Internet service providers,
both with this 80:20 mix of light and heavy users. One
provider quadruples its capacity; the other doesn't. But
TCP still doles out the upgrader's capacity in the same
way. So the light users, who used to have a measly
20 kb/s share, now get a measly 80 kb/s-still barely

better than dial-up. But now the 80 light users must
pay substantially more for four times the long-distance
capacity, which they hardly get to use. No rational network operator would upgrade under these conditions-
it would lose most of its customers.
But there is plenty of evidence that Internet service
providers are continuing to add capacity. This is partly
explained by government subsidies, particularly in the
Far East. Equivalently, weak competition, typical in
the United States, allows providers to fund continued
investment through higher fees without the risk of losing customers. But in competitive markets, common in
Europe, service providers have had to attack the root
cause: the way their capacity is shared.
Network providers often don't allow TCP to give all
the new capacity straight to the heavy users. Instead
they impose their own sharing regimes on their customers, thus overriding the worst effects of TCP's broken regime. Some limit, or "throttle," the peak-time bit
rate of the peer-to-peer customers. Others partition
the pipe to prevent heavy users encroaching on lighter
ones. Increasingly, the share of Internet capacity you
actually get is the result of this tussle between TCP
and the service providers' allocation schemes.

Time

Weighted TCP sharing
www.spectrum.ieee.org

DEcEmbEr 2008 * IEEE SpEcTrum * NA

http://www.spectrum.ieee.org

Table of Contents for the Digital Edition of IEEE Spectrum December, 2008