Re: [ledbat] "Oh Noes, the Internetz will Melt Down..."

[Richard Bennett <[e-mail]>]

This is what we've seen in P2P/BT implementations in the past. Check the 
configuration options in the Azureus agent that's part of most standard 
Linux distributions: it has a GUI option to set the DSCP value for its 
BitTorrent packets, which permits any old value you want.

So I'd expect Vuze (sponsor of Azureus) to add user-controllable knobs 
to set backoff parameters, consistent with their evident design 
philosophy.  The AIMD algorithms are an essential part of the Internet 
infrastructure, even though they're implemented in code that runs on the 
end system, so any large-scale alteration is going to have some very 
interesting consequences to other infrastructure components that 
implement RED and smart discard strategies. Consequently, I'm very 
skeptical of putting a lot of power over these things in the hands of 
the pirates. We know what their intentions are.

That being said, I'm all in favor of limited experiments. Just don't 
break the Internet in the process.

RB

Nicholas Weaver wrote:
>
> 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.
>

-- 
Richard Bennett

_______________________________________________
ledbat mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ledbat