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

[Richard Bennett <[e-mail]>]

How serious is this problem with cable modems that get buffer overflow 
because they don't flow-control their Ethernet links? It sounds like a 
poor implementation that can be dealt with at level 2 without disturbing 
RED and similar tweaks.

I'd be glad to see a real scavenger transport class, but remain 
skeptical that it can be implemented effectively solely in a network 
endpoint. This is one of the things that DSCP was supposed to do, after all.

RB

Woundy, Richard wrote:
>> 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.
>
> Have we established that there is "no effect on the ISP congestion
> problem one way or the other"? I missed that.
>
> I could imagine that a LEDBAT flow with delay-based controls might
> stabilize at a lower transmission rate than a TCP flow.
>
> -- Rich
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Nicholas Weaver
> Sent: Monday, December 01, 2008 4:54 PM
> To: Richard Bennett
> Cc: [e-mail]; Nicholas Weaver
> Subject: Re: [ledbat] "Oh Noes, the Internetz will Melt Down..."
>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ledbat
>   

-- 
Richard Bennett

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