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."

Comments

Re:Best of intentions

[boyko.at.netqos]

I agree with you Seanadams, but I just finished an interview with Simon Morris and it's not that he's saying that the way TCP handles packet loss is a particular problem, he just thinks he can do better.

BitTorrent essentially already has it's own methods to deal with dropped packets of information - it gets the information from elsewhere. Moving to UDP eliminates the triple handshake, and it eliminates throttling down packet sizes in response to a dropped packet.

The only problem is that it also eliminates the Layer 4 [transport] traffic congestion safeguards, which is why BitTorrent is looking to establish new and better ones at layer 7 [application].

Re:Best of intentions

[seanadams.com]

Detecting maximum throughput via packet dropping is really bad in high-latency links and in applications that need low latency.

I disagree. Please be more specific. First, what exactly do you believe is the problem? Secondly, how else would you do it (on an IP network)?

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.

So you're saying it's possible to implement it with a bug? I've recently found a heinous bug in a recent Redhat kernel which would result in _deadlocked_ TCP connections. It happens to the best of us.

Re:Best of intentions

[TheRaven64]

No it isn't. The size of the window can be adjusted to compensate for this. With a larger window, you get more throughput over high-latency links at the expense of having to wait longer for retransmits when they are needed. Modern TCP stacks dynamically adjust the window size based on the average RTT for any given link.

Where where?

[Emperor Zombie]

"Hear", not "here".

Re:Where where?

[Zironic]

I'm not sure, bouncing stones could be pretty painful.

The problem is...

[wolfbyte18]

we have an opportunity to detect end-to-end congestion and implement a protocol that can detect problems very quickly and throttle back accordingly so that BitTorrent doesn't slow down the internet connection
----
The major problem I see is that UDP doesn't play as nicely as TCP. Not by a longshot.

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.

As soon as TCP's throttling kicks in, space will be cleared in the tubes. uTorrent will be able to send more data through UDP without noticing any loss, so it'll quickly move to fill this space. Then, TCP gets hit with more data loss - and goes slower. It seems like a vicious cycle.

Re:The problem is...

[seanadams.com]

The major problem I see is that UDP doesn't play as nicely as TCP. Not by a longshot.

That statement makes no sense whatsoever. It's the same as saying "IP doesn't play as nicely as TCP". They are not comparable.

You have to be talking about whatever transfer protocol might be implemented ON TOP OF UDP, because UDP is merely a datagram protocol. It's nothing more than an IP packet plus port numbers.

In other words, I could write a simple program which blindly fires UDP packets at the rate of 1GB/s. This would kill my internet connection. I could also write a program which transmits one UDP packet per hour. This would have no effect. See what I mean? It's entirely a function of the application.

Re:Best of intentions

[sudog]

Please mod parent up. This place is so damn full of armchair wannabe network experts who've clearly no understanding of how TCP congestion avoidance works it's bordering on the physically painful.

Remove TCP-like requirements, and it's a WIN.

[sudog]

TCP guarantees in-order, mildly error-corrected, delivery of transmitted *DATA*. Not packets. It is a streaming protocol where the data being transmitted is of unknown and indeterminate length, or open-ended length. Since BT already doesn't care that files arrive in pieces at the beginning, middle or end (well, it does a little, but not enough to matter) then you can relax and basically eliminate one of the TCP guarantees right there: in-order delivery of data.

You can eliminate sliding windows, ACK-based retransmits, fast-retransmission, and pretty much every other mechanism that TCP uses to guarantee in-order delivery of data. You can simplify it and the application itself beautifully, and provided it correctly throttles back based on detected packet loss (it MUST be exponential back-off,) you end up with a net win for those reasons. The application can set up its own optimised data structures that don't necessarily have (but likely will end up having anyway) the overhead of an OS-backed TCP stack.

I mean who cares if you miss pieces, until the end when you can re-request them?

Heck, there are already P2P apps that use a UDP-based transfer mechanism and they are WAY less impactful on systems that a typical BitTorrent stream is. They way the hell slower, too, but that's not the point.

I do think there is a point that bears repeating: BT *MUST* have exponential back-off. If it doesn't there is logic already built-in to core routers, ISPs, and firewalls that WILL drop the connection more severely when the endpoints don't respond properly to an initial packet-drop attempt at slowing them down.

There are some really nice academic papers about it, and there are lots of algorithms and choices that companies have. They all assume TCP-like back-off on the endpoints, and they ALL uniformly punish greedy floods.

Re:Best of intentions

[rxmd]

On top of this TCP hasn't seen a major update since the 80's.

Uhh, TCP Vegas, TCP New Reno, BIC and CUBIC? All of which have been implemented in the Linux kernel? TCP has only been standing still since the 80's if you're using an OS from the 80's... or a Microsoft OS.

Note that the only one of those which made it into an RFC is New Reno, aka RFC 2582, which has been implemented in the Windows TCP stack since Vista, along with a number of other recent RFCs.

The others are basically different suggestions for implementing TCP congestion control. Microsoft has its own variant of those (Compound TCP, which is quite similar to TCP Vegas and has also been ported to Linux).

Your 1980s comment is not quite up to date, of course. Microsoft has been sticking to their BSD-based implementation of the TCP stack for quite a long time (too long in fact), but with Vista it's been undergoing quite a bit of change. I know it's unpopular to say something in favour of MS and/or Vista here and I'm far from being a MS apologetic, but it's worth actually reading their Cable Guy columns every now and then to be up to date with regards to what the Windows network stack actually does and doesn't do - especially if you are a sysadmin or interested in developments in the TCP arena.