[e2e] Skype and congestion collapse.

[Michael Welzl]

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

This is not an in-depth study, but some of my students did simple
measurements in a local testbed, and found that the payload was UDP
and it did not react to congestion (strangely, though, it did make packets
smaller plus increase the packet rate - thereby maintaining the same
bitrate - during long speech pauses). This, of course, may depend on
many things - the version, settings etc; the results are really preliminary.
Still, they at least indicate that Skype doesn't react to congestion.


> 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 agree, and I also tend to agree with Jon that it's just "occupying a
convenient niche". On the other Marc Herbert did also have a point when
he explained his experiences with an access link yesterday, didn't he?

I also don't believe in a global congestion collapse from Skype, but
it's still an interesting application with interesting applications. For
one,
PSTN and the Internet are two different beasts. I have a dedicated
cable going out of my house for each of the two, but the Internet cable
is the one I'd like to use for several things at the same time.


> 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

Do you mean that it uses TCP?
I never even personally used it, so perhaps I should just shut up here -
who knows, maybe my students just set "PROTOCOL = UDP"
somewhere in its options...


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

I agree that this is an interesting topic.


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

You didn't give that definition in your email, you just said that it's
well defined. What you state above seems to me to be a reasonable
definition, though; this definition may be in people's minds, but I don't
know of a paper or RFC out there somewhere that is generally
accepted as being the one which gives the definition.

I'm not trying to be picky here - note that I myself said:

> So how is it defined? I think we all share the general idea that the
> "collapse" is when the network just becomes unusable, but I'm
> not sure whether we have a really concise definition that is generally
> agreed upon.

I didn't like my own definition, couldn't think of a better one and
wondered if we had one somewhere out there.


> 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

all three of them really do use the term "congestion collapse", so I was
confused about how it really is defined. Again, I like your definition
above, but I never saw it before.


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

Ah, I see your point; interesting. On the other hand, VoIP is peer-to-peer
whereas streaming video is often client-server. In the latter case, the
applications should (and indeed appear to) react for their own sake
because not responding to congestion limits the number of clients that
can be served at the same time. It's a matter of incentives - in a VoIP
scenario, nobody has an incentive to react to congestion - I could
only hurt other flows, not my own.

But VoIP may be a bad example because of the little traffic that
it generates. I believe that a similar application that causes more
traffic could be more harmful than such client-server applications;
perhaps a video telephone, but nobody ever wanted them, and
nobody ever will IMO  :-)


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

Hm ... in any case, these are interesting thoughts!

Cheers,
Michael