Changing the game with μTP
blog.bittorrent.com
Changing the game with μTP
1–10 of 20 posts
Re: Changing the game with μTP
#2I don't think the article documents any details. Maybe I missed a link.
Re: Changing the game with μTP
#3This new protocol uses packet latency based throttling instead of the packet loss based throttling of TCP. I don't think the article documents any details. Maybe I missed a link.
Re: Changing the game with μTP
#4Re: Changing the game with μTP
#5This new protocol uses packet latency based throttling instead of the packet loss based throttling of TCP. I don't think the article documents any details. Maybe I missed a link.
So my question is, why wouldn't you get the same effect by running BT on top of a network stack using Vegas?
Someone flash the tptacek signal!
Re: Changing the game with μTP
#6This new protocol uses packet latency based throttling instead of the packet loss based throttling of TCP. I don't think the article documents any details. Maybe I missed a link.
Latency based congestion control already exists for TCP[1]. So my question is, why wouldn't you get the same effect by running BT on top of a network stack using Vegas? Someone flash the tptacek signal! [1] http://en.wikipedia.org/wiki/TCP_Vegas
You probably would, but Windows doesn't support Vegas.
http://www.ietf.org/mail-archive/web/p2pi/current/msg00052.h...
Re: Changing the game with μTP
#7What's unsaid here is that uTP is an undocumented protocol that isn't available to other BitTorrent implementations like Azureus/Vuze, potentially making them second-class citizens.
Simon Morris
Posted October 8, 2009 at 5:52 pm
As a matter of fact µTP is indeed a replacement for TCP, so we think the name is appropriate. You can check out standardization work which we’re chairing at the IETF called the LEDBAT working group
Re: Changing the game with μTP
#8This new protocol uses packet latency based throttling instead of the packet loss based throttling of TCP. I don't think the article documents any details. Maybe I missed a link.
Latency based congestion control already exists for TCP[1]. So my question is, why wouldn't you get the same effect by running BT on top of a network stack using Vegas? Someone flash the tptacek signal! [1] http://en.wikipedia.org/wiki/TCP_Vegas
If you assume that your own uplink is the only bottleneck to be dealt with (say you are serving torrents over a DSL line) then this is reasonable, but I don't think I'd want to yield to all TCP users everywhere with all of my outgoing traffic.
There are also some scary comments in the notes from before it was rolled into the kernel, like the code doesn't handle route changes.
I can see why a vendor would choose something over which they have control.
Re: Changing the game with μTP
#9What's unsaid here is that uTP is an undocumented protocol that isn't available to other BitTorrent implementations like Azureus/Vuze, potentially making them second-class citizens.
from the bittorrent.com comments, a quote from a high-up at BT: Simon Morris Posted October 8, 2009 at 5:52 pm As a matter of fact µTP is indeed a replacement for TCP, so we think the name is appropriate. You can check out standardization work which we’re chairing at the IETF called the LEDBAT working group
"Framing is not on the WG's charter."
http://www.ietf.org/mail-archive/web/ledbat/current/msg00117...
Re: Changing the game with μTP
#10What's unsaid here is that uTP is an undocumented protocol that isn't available to other BitTorrent implementations like Azureus/Vuze, potentially making them second-class citizens.