Slashdot Mirror
BitTorrent Calls UDP Report "Utter Nonsense"
Ian Lamont writes "BitTorrent has responded to a report in the Register that suggested uTorrent's switch to UDP could cause an Internet meltdown. Marketing manager Simon Morris described the Register report as 'utter nonsense,' and said that the switch to uTP — a UDP-based implementation of the BitTorrent protocol — was intended to reduce network congestion. The original Register report was discussed enthusiastically on Slashdot this morning."
Because application-specific knowledge allows easier and often better optimizations than application-generic protocols, which have to be good enough for all applications at the expense of top end performance for specific applications. Isn't it obvious?
Higher Logics: where programming meets science.
I wonder if you know what you're talking about. TCP is a great general-use protocol, as is UDP. But for specific cases, like this one, developers will tend to roll their own as an extension to UDP to fit their needs.
Take any modern networked game. It will not use straight TCP, as that's stupid, nor will it simply use UDP because that doesn't work, either. TCP is fine if you're writing apps that require data to get to the other end, without regards to time taken, but if you need a happy middle-ground you need to do it yourself.
TCP does two things at the cost of some overhead: it ensures packets arrive in order and it ensures they arrive. While doing that, it also has to ensure that in the case of network congestion, packets are resent within reasonable time while being fair and allowing each TCP connection an equal share of the speed and bandwidth. The problems TCP solves are at the root of the success of bittorent; bittorrent is extremely good at spreading traffic in such a way that links that have those problems are avoided. It can do this since the order in which the packets arrive does not matter and in fact it does not matter whether they arrive from a certain host at all; it can simply request a lost packet from another host minutes or hours later. In the case of TCP/IP there is no provision to handle such a case; it keeps trying to get the packets at their destination in the right order as quickly as possible.
So none of the problems that TCP solves affect bittorrent and all the overhead that TCP causes, however small, serves no purpose in this case. Instead of many small TCP ACKs, resends, negotiation, and what else TCP does, bittorrent will do just fine with one status update every now and then, which it can conveniently combine with the packets that are sent the other way anyway. Therefore, IMHO, using UDP for bittorrent is fine; it will help spread bittorrent traffic even better over the fastest links while using less bytes of network traffic and it might even end up making it easier on the Internet since now bittorrent traffic no longer has to fight with other TCP connections for a fair share of the bandwidth; it can be tuned to get just a little bit less.
Of course they can fuck it up completely and fill the poor pipes of the Internet with loads of packets that never arrive, but they don't have to; it is not inherent to this solution and therefore such rumours should be classified as... FUD.
Disclaimer: I did not RTFA and now practically nothing about TCP/IP :-)
0x or or snor perron?!
There are a lot of good reasons why BitTorrent should use a UDP file transfer protocol, but I probably wouldn't put TCP's congestion control mechanism on the top of the list.
:)
If you're going to argue UDP, you might as well bring out the major benefits:
* Going to a NAK-based or hybrid NAK/ACK-based protocol which can significantly improve performance over high latency or poor connections
* Multicast - assuming anyone implements IPv6 or multicast over the internet
* NAT to NAT transfers (you can do it with TCP, but it is just harder and you generally have to build a user-space TCP stack anyway).
* Faster start time since you no longer have to do a three-phase startup and all the annoying things Microsoft does to prevent people from starting too many per second
There are plenty of UDP-based protocols with TCP-friendly congestion control mechanisms out there and plenty of research into the subject.
The biggest problems I see happening here revolve around different BitTorrent clients all reimplementing uTP and doing a poor job at it. I'd like to see a spec for uTP and a public domain implementation to help minimize the problems that could pop up.
And don't forget that those IETF PhD's couldn't design a better way to upgrade IPV4 but the incompatible and essentially non-interoperable IPV6 (please don't argue about dual stacks or something similar.)