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."
...we should have known they are full of shit.
Obligatory blog plug: http://www.caseybanner.ca/
Detecting maximum throughput via packet dropping is really bad in high-latency links and in applications that need low latency. It is also apparently easy to implement TCP in such a way that overall transfer speed takes a nosedive when latency gets high, as evinced by Microsoft having done just that.
I don't really see how this is going to kill VoIP and online gaming. Those two services are big users of UDP, no doubt, but its not like all of a sudden the explosion of UDP requests is going to sqeeze VoIP traffic out. If anything it should encourage ISPs and providers to increase the rate of their roll out of new tech.
This move should bring into focus the last mile problem that is the real source of most of the internet connection speed debate. I don't care how the solution ends up working, but I think there needs to be a plan given that most of the plans I have heard involve several years of lead time.
And why, exactly, does Simon Morris think that he, single-handedly, can do better than the folks at the IETF, most of whom have PhDs in computer science? Seems a bit presumptious, if you ask me.
My blog
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.
Maybe he has spent years working with the technology he is trying to one up?
This relates directly to a reply I just finished on another thread regarding whether a degree is required for success.
This Morris character may be right, he may be wrong, but you citing the education level of his rivals blows your point out of the water IMO.
Whatever TCP replaced was probably designed by a bunch of PhDs too. I really don't see your point.
If you mod me Overrated, you are admitting that you have no penis.
As soon as TCP notices a single packet loss, the Jacobson Algorithm kicks in and it's throttled to maybe 50-60%, and raises the limit slowly. I highly doubt that uTorrent's reworked version of UDP will play this nicely.
You're right; uTP is actually nicer than TCP.
Bittorrent doesnt need reliable communications, and congestion control can be tuned for bittorrent connections.
IMHO its a good move.
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.
does Simon Morris think that he, single-handedly, can do better than the folks at the IETF, most of whom have PhDs in computer science?
You really have a very strange over-estimation of the value of a PhD. It doesn't mean you're a super-genius, you're smarter than everyone (or even anyone) else, or that you're always right. It simply means you've been willing to go through some schooling. That's it. Hopefully you've learned something from that education.
There's plenty of examples of non-PhD's making major contributions. The WWW was largely invented by someone with a degree in physics (undergrad I believe), with no degree in computer science. Linus Torvalds only attained a mere masters degree in Computer Science, but yet his OS seems to have become a bit more successful than quite a few other OS's written by people with more education.
AccountKiller
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.
Having said that, your suggestion for improving things by smarter selection of peers is good. Unfortunately the Internet doesn't have any easy mechanism to indicate which peers would be better. Good solutions would likely have to be built on additional knowledge - which implies a database to hold and serve it - which implies a new central infrastructure and queries of it - which both breaks the decentralized model and provides additional points of attack if the ISPs continue to treat this as a war and attempt to suppress "unauthorized"/"enemy" torrents.
I posted a while ago an idea I'd like to see for a Request For Comment (RFC), a new protocol ISPs could easily run in-house. See http://slashdot.org/comments.pl?sid=590741&cid=23883635
Actually even Cisco could add such a protocol to their routers which merely look up the internal routing protocol to decide which IPs were local, and anything out a border gateway (routes advertised via BGP) could be regarded as "non-local". Anyone from Cisco here?
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.)
Wait, so does that also mean that Vista was written by Copyright Lawyers?
As it happens, yes it was. And when you think about, that explains a lot.
The higher the technology, the sharper that two-edged sword.
Harvard isn't a "local technical college"
If I have nothing to hide, don't search me
Further, the guys at IETF are not tasked with coming up with optimal protocols for specific applications. They're not necessarily even tasked with coming up with better versions of TCP. There are tons of things they have come up with that improvements on what we use now, for that matter, that haven't been picked up by the Internet at large.
The expertise of the IETF members really has no bearing on this matter. If you were trying to actually recreate TCP (i.e., a general-purpose protocol), and the IETF said that theirs is better -- they're probably right. That's not what's going on here.
There's plenty of research to suggest that packet loss is not the most attractive indicator of congestion, not merely because it involves losing data, but because it comes very late in the development of an instability. Under congestion, router queue depths go up, and you get observable latency spikes. To exploit this observation effectively you need to timestamp packets, of course.
As many others have noted, there's a second issue with TCP, which is that it is hell-bent on in-order delivery, which is an utterly pointless property for almost all modern applications—not just file sharing, but web applications as well. And it conspires to absolutely hog buffer memory on modern fast long-haul pipes, where to deliver data serially you need hundreds of megabytes in window—hundreds of megabytes that, absent TCP, could already be committed on disk.
TCP is semantically well-suited only for interactive login. UDP is the protocol of choice for everything else. It is just unfortunate that good congestion control algorithms are tricky to write, and that the socket paradigm doesn't provide a good vocabulary for packetisation. These two conceptually orthogonal problems have conspired to shut out the superior solution in almost every domain.
Autonomous system numbers are the perfect metric.
http://en.wikipedia.org/wiki/Autonomous_system_(Internet)
Of course it runs NetBSD. BTC: 1NT7QvbetmANwaMzhpVL6
I just got back from living in Japan not too long ago. Over there, we got 100 mbps up AND down for about ~$40/month. Near the end of my stay there, I got a letter from my ISP stating that they're going to start implementing a bandwidth cap, and that no user can upload 500gb/month, but downloading is still unlimited.
This year, I read on Slashdot that AU/KDDI is unrolling a 1gbps line for a similarly cheap price.
If you want my sympathy for ISPs in America, get back to me when I get even one tenth of the service I got in Japan. I'd like to extend a big middle finger of gratitude to all American ISPs. No one is spouting the gloom and doom over in Asia, and meanwhile, they're shooting ahead into the future of the internet. Asia's been rolling out fibre-optics, at great cost to them, but with spectacular results. Conversely, we sit on our asses and wonder how we can charge more money to more users to put them through the same amount of pipes without upgrading infrastructure.
**** you, American ISPs.
Signed,
Someone who's seen the other side of the world, and it was better.
You really have a very strange over-estimation of the value of a PhD. It doesn't mean you're a super-genius, you're smarter than everyone (or even anyone) else, or that you're always right. It simply means you've been willing to go through some schooling. That's it. Hopefully you've learned something from that education.
PhD doesn't mean you attended some schooling.
PhD means you gave some schooling.
You have to contribute something new, and pass peer review. I can't think of a better way to prove you really know your topic than to teach something new, in that topic, to a bunch of knowledgeable critics.
If you don't believe me, pick a topic, teach it to a bunch of kids, and see if you can answer all the questions. You'll soon find out just how well you know your topic.
Yes, non-PhDs do contribute. They have made large contributions. And so do people without high school. That's also the point of an honorary doctorate (except in politics)
Am I the only person who hates those ridiculous jokes that have a made-up story just to set up a pun? The whole point of a pun is that both meanings make sense. Otherwise you can turn anything into a pun. An example: When Victoria and David Beckham got married on thrones someone on the now show said:
People in crass houses shouldn't stow thrones.
See? It relates to something that wasn't just made up for the pun.
Use round trip time? Try increasing TTL to find the closest nodes with the desired content? Why would you need a central database, when many end-to-end metrics can give you information about distance?
TCP/IP replaced NTP, and the GP is correct: NTP was designed by the guys who built the Arpanet, yet it got replaced.
This reminds me of grc.com's dire warnings that Windows XP's "raw sockets" would cause chaos on the Internet. Total and utter bunk. But I guess that's what you should expect from the Register.
XML is like violence. If it doesn't solve the problem, use more.
How, exactly, are they similar? One's a datagram protocol, the other is a stream protocol. The two couldn't be more different. The only thing they have in common is that they both run over IP.
You are not alone. This is not normal. None of this is normal.