A column in The Register claims, amongst much wailing and gnashing of teeth, that implementation of BitTorrent-over-UDP (dubbed uTP) in the new alpha version of uTorrent, one of the official BitTorrent client applications, will end the Internet as we know it and completely congest the network. The title is “Bittorrent declares war on VoIP, gamers.”
Considering the fact that BitTorrent, Inc., has, if anything, always gone out of it’s way to avoid declaring war on anybody, this seemed to me a little bit odd.
I’ll admit that it kind of worried me – TCP has traffic congestion management built into the protocol, UDP does not. When UDP and TCP exist on the same network (for example, when rolling out VoIP on a corporate network), QoS policies are needed to keep UDP from taking up all the bandwidth while TCP meekly throttles back. Jim McQuaid has a Whiteboard series video up about it, and called it “Nice Guys Finish Last.”
The reason that UDP is popular is that it’s a lightweight protocol that doesn’t do much handshaking. It sends the data “that-a-way” and doesn’t particularly care if it makes it. That makes it perfect for VoIP, gaming, and other Internet protocols where latency is more important than throughput. TCP, with congestion control and packet confirmation built in, sacrifices latency for accuracy. A dropped packet in a phone conversation isn’t much to worry about, but a half-second delay is extremely annoying. On the other hand, a half-second delay in downloading a computer program isn’t much to worry about, but a dropped packet means that the program won’t run.
So, as a general rule, TCP runs data apps, while UDP runs real-time apps. Rudimentary QoS policies based on giving UDP packets higher priority may not be perfect, but they can be a good start to improving performance on simpler networks.
My concern was that putting BitTorrent, a non-latency sensitive application – on UDP would result in it receiving higher priority traffic. But after speaking to Simon Morris, the Vice President of Product Management at BitTorrent, Inc., I was assured that this wasn’t the case. Morris explained:
[Editor's Note: Some words got a little garbled in the phone conversation I had with Simon Morris, and he sent me an e-mail with clarifications. I've made corrections via strikethroughs. --ed.]
“BitTorrent obviously needs to be a accuracy-sensitive protocol but we believe it needs to also be …MORE sensitive to latency than TCP, not less sensitive.
This is to say that with uTP, we have taken UDP, implemented a layer of reliability and spent a great deal of time implementing a congestion control mechanism that is better than the one used in TCP (better = faster to detect issues, faster to react).
It’s not QoS, but rather a congestion management mechanism implemented at the end-user’s layer 7 [Application]. This will stop uTP from eating up
trafficbandwidth reserved for latency sensitive apps like VoIP and gaming. What’s more, the congestion management mechanism isn’t something we implemented as an afterthought – it’s the whole point of uTP.
In short, it seems that rather than using UDP as a way of getting around TCP’s traffic congestion features, the new protocol is rebuilding better traffic congestion features at layer 7, using the lightweight UDP protocol as a simple base. In short, to mangle a metaphor, they’re re-inventing a better wheel.
If uTP does congestion control for BitTorrent as an application, this could provide an answer to BitTorrent critics, and ISPs who claim that BT throttling is necessary because it’s “eating up bandwidth.” I asked how uTP implemented congestion control at Layer 7 [Application] rather than Layer 4 [Transport].
Morris: “So basically, what TCP does is that it
stopsdetects congestion only when it detects packet loss and then it throttles back. Because we control both ends of the transfer, we can actually measure the single-trip time between when the packet is sent and a packet arrives. (Not round-trip-times but single-trip-times…) We have essentially, an ability to monitor single trips over the internet across millions and millions of terminals, and we built an algorithm around that to do things like eliminate the discrepancy between the stockclocksettings on different terminals – to identify where there is actual – very fine grain, down to milliseconds – changes in the speed of which packets are arriving….”
“The way that prioritization policies are set [by network operators] is extremely varied, and so, it’s possible that [uTP-based] BitTorrent traffic will get a higher prioritization, but only in cases where it’s not causing any type of congestion at all… [uTP] will never trample over UDP based latency sensitive traffic, nor TCP-based traffic. [UDP is] designed to throttle back if there’s anything else on the line.
“I mean, it’s essentially designed to be – a term that we use internally is – a “scavenger protocol.” It scavanges and uses bandwidth that is not being used by other applications at all, and it’s designed to throttle back very very quickly in case there is any type of congestion on the line.
“Unfortunately the way that TCP works is – just profoundly broken as a method of control congestion on the Internet. Especially when there are applications out there that are designed to get the most out of network bandwidth – like BitTorrent. People have tried to make TCP better, but the problem is that it’s such a huge implementation task to make it happen, because you need to upgrade all of the Web servers and all of the terminals. Now, the insight here is that in
mostmanycases, we have control of both ends of the [communication]. So we can actually take the right steps in the direction of solving this problem.
Those concerned about BitTorrent (either classic or newfangled) traffic on their networks might want to check out a solution designed to monitor and track the types of traffic going on the network, including information about what applications are transmitting and receiving what amounts of traffic.