3 ms·
The article is a little light on technical facts. The previous Bittorrent protocol used TCPs congestion control. Any reason to believe that their UDP+µTP replac
by mikedouglas 17y ago
The article is a little light on technical facts. The previous Bittorrent protocol used TCPs congestion control. Any reason to believe that their UDP+µTP replacement will outperform it?
Edit: found the draft RFC: http://www.bittorrent.org/beps/bep_0029.html http://www.bittorrent.org/beps/bep_0029.html. Looks like the congestion control is window- and latency-based.
| "The window size in the socket structure specifies the number of bytes we may have in flight (not acked) in total, on the connection."
| "Each socket aims to never see more than 100 ms delay on the send link. If it does, it will throttle back."
- tybris 17y agoIt's very unlikely. I've seen a bit of the research in this area and all this stuff has been tried before with marginal success. Van Jacobson did a pretty good job.
- wmf 17y agoThe point of uTP is not to outperform TCP but to underperform it, using the network's idle bandwidth but not competing with regular TCP.
- nas 17y agoA magic number like 100 ms seems like a bad idea. Also, it's not clear to me what happens when minimum path latency is > 100 ms. Based on my superficial understanding, the uTP rate would go to (nearly) zero.