[e2e] Skype and congestion collapse.

[David P. Reed]

Michael Welzl wrote:

>
>You're doing the Real folks wrong: in our tests, RealVideo _DID_ react to
>congestion. The way it did so was a little strange, but what the heck,
>eventually it reduced its rate. Having tested a number of other
>applications, I'd say that this is more than you could hope for  :-
>  
>
And exactly what evidence are we considering that Skype, which uses the 
TCP stack in the OS, does not reduce its packet flow when congestion 
occurs?  My mention of other streaming services was to point out that 
they present a heavy load, more than Skype does.   So if the Skype load 
is going to cause "congestion collapse" (see below), we would already be 
there.   There is a limit to Skype's load - each phone call requies two 
(2) humans at the endpoints, who probably are not doing other things 
(like making PSTN calls or watching streaming videos or listening to 
iTunes).   Hardly a recipe for unbounded demand....

I wasn't actually referring to whether Skype responds to congestion.  As 
a user I see no evidence that it tampers with TCP, but I plan to dig 
further.   Actually, transmitting continuous 10KB/s is a nice, simple 
strategy for avoiding stupid interactions between "silence detection" 
and TCP's flow control algorithm, which is really only tested for bulk 
async delivery traffic (that's why I get red and angry every time the 
Internet Drag Racers focus on how fast their latest tweak on TCP runs 
over fiber - if even one graduate student were to look closely at the 
larger class of apps that run over TCP, such as HTTP 1.1, POP3, SMTP, 
... they would stop focusing on how fast one can travel over a standing 
quarter mile flat track and figure out how to improve the performance of 
real cars in real cities.

>
>  
>
>>Congestion collapse is a well-defined term.   It's not the plural of 
>>    
>>
>
>I disagree:
>ftp://ftp.rfc-editor.org/in-notes/rfc896.txt
>versus
>http://www.cse.ohio-state.edu/~jain/papers/cr1.htm
>versus
>http://www.icir.org/floyd/end2end-paper.html
>
>  
>
I said the term *congestion collapse* as a resulting effect was defined 
- and it is - a sustained reduction of throughput that persists after a 
period of overload.   If there is an alternate definition in paper 2 and 
3, I certainly can't find it in the words there.   Perhaps you missed 
the word "collapse" in my point, which matches with the word collapse in 
paper 1?    The other papers refer to congestion - a much less precise 
term than "congestion collapse" I agree.   I made no reference to the 
number of causes that might lead to "congestion collapse".   I referred 
in an ironic way "c.c. is not the plural of heavy load" to refer to the 
fact that heavy loads on the Internet do not necessarily cause 
collapse.  There are any number of reasons - one is that TCP backs off, 
one is that humans back off, etc.  And of course the length of the 
control loop involved in the backoff is crucial - if the backoff happens 
early and persists long enough, sustained reduction in performance 
doesn't happen.

In other words, the difference between congestion and congestion 
collapse does lie in the control loop.

Unlike video or audio streaming, phone calls have, necessarily, a very 
tight feedback loop - users find zero value in throughput without 
tightly bounded latency in phone calls.   They hang up if their calls 
get even the slightest bit unreliable, and they hang up if the 
end-to-end delay gets over about 100 msec.

This does not happen in audio or video streaming.   Those are therefore 
a much likelier contributor to "congestion collapse".

Mere congestion is usually a spur to investment, by the way.   
Businesses whose parking lots are full attract investors to build 
parking lots, *even when there is no charge for parking*.   Why?   
Because its clear that the businesses are popular.   In the same way, if 
Skype actually caused congestion at a substantial level, I have no doubt 
that its users would find a way to pay to improve their highly desirable 
service.   Funny thing - the Internet got built out because so many 
companies found that users really wanted to conduct business with them 
on websites.

There is no denying that "congestion collapse" reflects a brittle 
response that is to be avoided, but preventing congestion may actually 
backfire, because it removes one of the economic signals that cause the 
investment that reduces the congestion.