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...

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:richard@bennett.com] 
Sent: Monday, December 01, 2008 7:17 PM
To: Woundy, Richard
Cc: Nicholas Weaver; ledbat@ietf.org
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: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf
Of Nicholas Weaver
Sent: Monday, December 01, 2008 4:54 PM
To: Richard Bennett
Cc: ledbat@ietf.org; 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
ledbat@ietf.org
https://www.ietf.org/mailman/listinfo/ledbat

-- 
Richard Bennett