On Dec 1, 2008, at 1:03 PM, Richard Bennett wrote:
I'm glad so many people have read my article, and I'd be happy to discuss it at length if it's appropriate. Broadband Reports, the info hub for file-sharers, ran an article on uTorrent 1.9 over the weekend under the title: "New UDP uTorrent Takes Aim At Throttling," highlighting the value of UDP-based file sharing for avoiding TCP- based fair traffic systems. It's clear that the users of BitTorrent see this as simply another means of grabbing more network resources.That being said, I'll gladly stipulate that BitTorrent, Inc., means well and has a heart of gold. But what happens when users can tune congestion avoidance and backoff parameters through a GUI? I'll go out on a limb here and say some of them may not be altruistic.
Where is the suggestion that users will be able to control the congestion control parameters?
IF the algorithm is equivalent to what was presented at the IETF, namely, a delay-based ADDITION to a TCP-like AIMD, this will only have a net benefit, as this will still stabilize out like any other TCP flow (so no effect on the ISP congestion problem one way or the other), but will have a huge benefit on the buffer-oversizing congestion problem.
Likewise, the notion that this can avoid traffic management is pretty delusional. The only thing a UDP shift avoids is RST-injection based management, which is a crude tool. Any in-path management (which, btw, Sandvine supports, but was simply not deployed in this way by Cox, Comcast, and others) can block a UDP flow just as easily as a TCP flow. Likewise, router ACL injection can block flows as well.
There are plenty of things to dislike about bulk-data P2P. But this is probably not one of them.
_______________________________________________ ledbat mailing list ledbat at ietf.org https://www.ietf.org/mailman/listinfo/ledbat
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.