See The Register for my follow-up on the BitTorrent meltdown story:
The internet’s TCP/IP protocol doesn’t work very well. As the internet’s traffic cop, it’s supposed to prevent applications from overloading the network, but it’s at a loss when it comes to managing P2P applications. This deficiency, generally known to network engineers but denied by net neutrality advocates, has been a central issue in the net neutrality debate. BitTorrent Inc has now weighed in on the side of the TCP/IP critics.
The next official release of the uTorrent client – currently in alpha test – replaces TCP with a custom-built transport protocol called uTP, layered over the same UDP protocol used by VoIP and gaming. According to BitTorrent marketing manager Simon Morris, the motivation for this switch (which I incorrectly characterized in The Register earlier this week as merely another attempt to escape traffic shaping) is to better detect and avoid network congestion.
Morris also told the media this week that TCP only reduces its sending rate in response to packet loss, a common but erroneous belief. Like uTP, Microsoft’s Compound TCP begins to slow down when it detects latency increases. Even though TCP is capable of being just as polite as BitTorrent wants uTP to be, the fact that it hides its delay measurements from applications makes it troublesome for P2P clients with many paths to choose from. But it’s sensible to explore alternatives to TCP, as we’ve said on these pages many times, and we’re glad BitTorrent finally agrees.
We strive to be fair and balanced. The nut is that we don’t actually know whether BitTorrent’s new protocol is going to work any better than TCP, as there’s no hard data available on it.
Technorati Tags: net neutrality, Internet
Do you mind providing the source of this?
That’s what Eric told me himself.
Actually, RIchard, TCP does slow down in the face of high latencies due to windowing. Once the window size has been exceeded, the sender will transmit no more data until it gets an acknowledgement — whose arrival time will depend upon the round trip latency.
In any event, even if BitTorrent’s software is really trying to be “courteous” (and the jury’s out on this…. Do you think we can trust an implementation by, say, Azureus not to hog bandwidth?), all this means is that it will take all the bandwidth it can before the network is crippled.
This means that, if ISPs are forced to allow the new protocol through with no throttling, their networks will forever be close to saturation no matter how much capacity they add. And because it’s P2P, the cost of any added capacity will be borne by the ISP instead of the content providers who are benefiting from it. What incentive will ISPs then have to add capacity to their networks?
There’s no single rule for TCP backoff, since every version tweaks the algorithm in some way, but yes, the general rule for recent Linux stacks has been to use inceased latency as a clue to enter the congestion avoidance state.
And no, I certainly don’t trust Vuze’s Azureus to get it right, since they give users the ability to set any DSCP they want right in the GUI. The history of all P2P companies is actually quite checkered with abuse of intellectual property rights as well as network abuses.