[e2e] congestion collapse definition

[Detlef Bosau]

David P. Reed wrote:
> Folks, I tend not to use the term "congestion collapse", though it is 
> in common use in the Internet community.
>
> The phenomenon I've been experiencing on the other thread about AT&T 
> 3G data access network configuration on this list, if I'm correct (as 
> I'm pretty sure I am) should probably be called "congestion collapse", 
> or else we need a new term.
>
> The phenomenon observed in Comcast's debacle with DOCSIS upstream 
> buffering should be called by the same term - again, buffering is 
> allowed to build on a shared queue carrying diverse traffic, without 
> providing any feedback that can be recognized by TCP's rate control 
> loop, leading to positive feedback and uncontrolled delay.
>

Hm. I think, you encounter two problems.

1.: Overbuffering. (Which you frequently mention yourself in the context 
of wireless networks.)
2.: And I have to guess here because I don't have any first hand 
experience with DOCSIS, the MAC algorithm used in DOCSIS or by Comcast 
respectively.

> If I look at Wikipedia, for example, at the definition of congestion 
> collapse there, it says that CC is characterized by large buffering 
> delays AND lost packets.  However, in the Comcast and ATT cases here, 
> the queues get so obnoxiously long (5-10 seconds) that users 
> presumably give up running apps long before packet *loss* sets in due 
> to overflow.

Isn't this a clear symptom of overbuffering? Particularly, as TCP is 
likely to see quite a number of RTO backoffs when starting a session?

This reminds me of the difficulty of TCP in establishing a proper ACK 
clock in wireless networks in case of "short time disconnections", which 
Lachlan mentioned some weeks ago.

However, when a queuing delay in wirebound networs grows to 5 or 10 
seconds, the queue is obviously dimensioned far too large.

> Back to my question: should this phenomenon be included in "congestion 
> collapse" (I believe so), or should we invent a new more specific name 
> (Buffer Madness?).
It is surely not congestion collapse, because the traffic growth in CC 
is caused by extensive retransmissions. So, CC is basically self 
induced. More precisely: The traffic growth is self induced and the 
resulting packet loss is self induced.

When, if, there is something self induced in your problem, this is the 
growth of the RTO. However, this is hardly a real self induction.

I think "buffer madness" or "extensive buffering syndrome" would be 
suitable.

Detlef

-- 
Detlef Bosau		Galileistraße 30	70565 Stuttgart
phone: +49 711 5208031	mobile: +49 172 6819937	skype: detlef.bosau	
ICQ: 566129673		http://detlef.bosau@web.de