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

[Richard Bennett <[e-mail]>]

Interesting paper, it's by the Glasnost people.

RED is a whole different animal than the buffer problem that's been 
presented here. RED (and AQM generally) is an attempt to prevent cycling 
by reducing stream rates before buffers overflow. It's quite different 
from tail-dropping an oversized buffer, and would not lead to 5 second 
delays on the DSL upstream.

RB

Woundy, Richard wrote:
>
> > 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...
>
>  
>
> I stumbled across this paper today, 
> http://www.imconf.net/imc-2007/papers/imc137.pdf. This text comes from 
> section 4.3.2:
>
>  
>
> "We found that 26.2% of the DSL hosts show a RED-style drop policy on 
> their upstream queues. The three providers
>
> owned by AT&T (i.e., Ameritech, BellSouth, and PacBell) exhibit 
> deployment rates between 50.3% and 60.5%, whereas
>
> all other DSL providers' deployment rates are below 23.0%. The partial 
> deployment of RED-style policies within ISPs
>
> could be due to heterogeneity in the ISPs' equipment. We did not 
> detect RED in any of the cable ISPs measured."
>
>  
>
> I suspect there are a lot of "poor implementations" out there, across 
> multiple ISP technologies.
>
>  
>
> -- Rich
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Richard Bennett [mailto:[e-mail]]
> *Sent:* Monday, December 01, 2008 7:17 PM
> *To:* Woundy, Richard
> *Cc:* Nicholas Weaver; [e-mail]
> *Subject:* Re: [ledbat] "Oh Noes, the Internetz will Melt Down..."
>
>  
>
> 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]> [mailto:[e-mail]] On Behalf
> Of Nicholas Weaver
> Sent: Monday, December 01, 2008 4:54 PM
> To: Richard Bennett
> Cc: [e-mail] <mailto:[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] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ledbat
>   
>
>
>
> -- 
> Richard Bennett

-- 
Richard Bennett

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