Changing the game with μTP(blog.bittorrent.com)
blog.bittorrent.com
Changing the game with μTP
http://blog.bittorrent.com/2009/10/05/changing-the-game-with-%ce%bctp/
4 comments
What'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
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
LEDBAT is only standardizing a small subset of uTP:
"Framing is not on the WG's charter."
http://www.ietf.org/mail-archive/web/ledbat/current/msg00117...
"Framing is not on the WG's charter."
http://www.ietf.org/mail-archive/web/ledbat/current/msg00117...
Don't forget: BitTorrent is a business that Bram Cohen built. Their goal is to sell their product, in this case, uses of BitTorrent the protocol to companies. They can hardly do this if BitTorrent is being blocked everywhere.
If they have special BitTorrent client to BitTorrent client information, it could be for use in their custom software that companies would use within their own product, not necessarily for public downloading usage (ex: WoW's software updates using BitTorrent).
I don't know if this is actually the case. But why couldn't it be a possibility?
If they have special BitTorrent client to BitTorrent client information, it could be for use in their custom software that companies would use within their own product, not necessarily for public downloading usage (ex: WoW's software updates using BitTorrent).
I don't know if this is actually the case. But why couldn't it be a possibility?
That should be a nonissue as long as the protocol is backwards compatible.
...The way the client talks to other clients has had to be completely re-built. As a side effect, because the new protocol so different, it is practically invisible to some of the nasty traffic shaping techniques that some ISPs have been using.
They're not even going to pretend other client will be able to support it in a timely fashion. Backwards compatibility is out the window if they really did implement everything documented in the article.
They're not even going to pretend other client will be able to support it in a timely fashion. Backwards compatibility is out the window if they really did implement everything documented in the article.
Good news, though: the code is open source.
I don't think so.
"source code for BitTorrent 6.0 ... will not be released"
http://www.slyck.com/story1566_BitTorrent_Addresses_Closed_S...
I wouldn't expect 7.0 to be any different.
"source code for BitTorrent 6.0 ... will not be released"
http://www.slyck.com/story1566_BitTorrent_Addresses_Closed_S...
I wouldn't expect 7.0 to be any different.
This 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.
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
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
It appears to me that if you use Vegas on your Linux machine then all of your TCP connections use Vegas, which will make you a second class citizen to all the Reno folk out there on the internet.
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.
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.
why wouldn't you get the same effect by running BT on top of a network stack using Vegas?
You probably would, but Windows doesn't support Vegas.
http://www.ietf.org/mail-archive/web/p2pi/current/msg00052.h...
You probably would, but Windows doesn't support Vegas.
http://www.ietf.org/mail-archive/web/p2pi/current/msg00052.h...
The article doesn't mention details but in the comments, Simon links to the IETF working group on this: http://www.ietf.org/dyn/wg/charter/ledbat-charter.html
Details of the protocol are here:
http://www.bittorrent.org/beps/bep_0029.html
http://research.microsoft.com/en-us/um/people/costa/papers/s... might be an interesting alternative/complement.
OTOH, http://conferences.sigcomm.org/hotnets/2009/papers/hotnets20... suggests that localization doesn't help that much.
Isn't http://en.wikipedia.org/wiki/Precision_Time_Protocol better than uTP?