[e2e] congestion collapse definition
detlef.bosau at web.de
Wed Sep 9 07:09:08 PDT 2009
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
> 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
Detlef Bosau Galileistraße 30 70565 Stuttgart
phone: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau
ICQ: 566129673 http://firstname.lastname@example.org
More information about the end2end-interest