[e2e] Skype and congestion collapse.

Jon Crowcroft Jon.Crowcroft at cl.cam.ac.uk
Sat Mar 5 02:32:37 PST 2005


In missive <099601c520de$1f4cc2c0$016115ac at dcml.docomolabsusa.com>, "James Kempf" typed:

 >>Maybe for the backbone, but what about the access networks? Capacity there
 >>is usually a lot less.
 
contention ratios in broadband access are an issue, but becoming less so with time.

bottom libe though is that an ISP that cannot cope with 10kbps (note one 1500 byte MSS TCP packet per second is
12kbps) is in big trouble

in the edge net/bottlneck,
as with the 10% tcp packet loss problem discussion, the point is not about
fancy steady state fluid flow approximations, but about the "corner case" discrete beheaviour
of protocols at low rates - 

so i see skype (and most voip tools) as occupying a convenient niche - i do NOT subscribe to the argument that we
could do any application at any fixed rate - if we all took 576kbps DSL lines and sent 24*7 MPEG2, we would (today)
cause trouble - but in a few years time, who's to say what the minimum entry point is?

 >>See RFC 3714 for some musings Sally Floyd and I went through on this topic.

 sure

by the way, Professor Angela Sasse and some PhD students at UCL did some of the definitive work
on user acceptance of variable quality video and audio
(see links from http://www.cs.ucl.ac.uk/staff/a.sasse/

unlike prior work, they used objective measures (e.g. using questionnaires and mean opinion
stuff that goes back to bell labs work 40+ years ago on audio capacity  and acceptable latency for
interactive work), the experiments (with ethics committee approval) used lie etector type stress measurement
(heatbeat, skin conductivity/temperature) while subjects carried out real tasks (e.g. interviewing student
applicants to university) over a video link with control groups etc etc - the audio and video qualities were varied
under controlled conditions to see if users were more or less stressed -

you know what: users do NOT like variable quality -if you  aregoing to support a given rate, dont go ABOVE it if
you are later going to have to go back down to that rate  0 if you have a lower rate, only support that.
this is critical for audio (but less so for video) - so all the work on fancy codecs and user/channel/codec
adaption we all did 2 decades back for 10 years - you know, was all misguided.

whats more, VERY few codecs actually lend themselves to smooth adaption anyhow - mostly they can only adapt in a
fine grain way (the way say a "tcp-friendly" multimedia flow over dccp or other is "supposed to"), at the higher
rates - at lower rates, most DCT based video codecs only vary coarse grain (e.g. frame rate or resulution in large
steps and  audio codec by actually chaning codec altogether) - This only makes matters WORSE from a usability
perspective. and not a lot from a network perspective.

so if you look at the Book we wrote on all this stuff (Internetworking Multimedia, Handley/Crowcroft/Wakeman - 
morgan kauffman pubs), we were wrong (though all the stuff on rtp and sip and realtime on IP and multicast there is
is still pretty up-to-date:)

cheers
 >>----- Original Message ----- 
 >>From: "Jon Crowcroft" <Jon.Crowcroft at cl.cam.ac.uk>
 >>To: "Emmanuel Papirakis" <papiraki at gmail.com>
 >>Cc: <Jon.Crowcroft at cl.cam.ac.uk>; <end2end-interest at postel.org>
 >>Sent: Friday, March 04, 2005 6:30 AM
 >>Subject: Re: [e2e] Skype and congestion collapse.
 >>
 >>
 >>> well so a back of the envelope calculation on skype would tell you that
 >>> even if everyone ran it, 24*7,
 >>> there must be enough capacity in the world for it -
 >>>
 >>> 1/ the PSTN has virtually zero call blocking probability in most europe
 >>> and north america-  so the underlying network has enough for 64kbps, and
 >>> skype is using 6 times less than that
 >>>
 >>> 2/ the internet is no longer an overlay on the core PSTN -= the core
 >>> internet has its own capacity - in the UK, just one ISP for example, the
 >>> UK academic net, has a 10Gbps backbone - there are several that big in
 >>> the UK and many european countries are similar
 >>>
 >>> 10Gbps is enough for 10M skype calls - thats 1/5 of the UK population
 >>> talking simulataneously assuming there is NO locality of calls...
 >>> if there's any locality at all (and there usually is, even ifd just
 >>> becuase of timezone differences (ok i know there's not much timezone in
 >>> the uK - ok, language differences, work, lunch breaks etc) then its no
 >>> problem...
 >>>
 >>> it would not be hard to upgrade the natl net to 40Gbps -
 >>>
 >>> in th next few years it ought to be easy to go another order of
 >>> magnitude without layering any more core fiber (just more lambdas)
 >>>
 >>> if there is a bandwidth crunch, imho, the solution is to do
 >>probe/measurement
 >>> based end user call admission control. There is not a lot of room for
 >>> congestion control _below_ 10kbps
 >>>
 >>> oh, skype isnt truly p2p afaik, it has servers- they will get
 >>> congested LONG before the net does. If they don't, it will be because
 >>> they have to raise revenue to scale them up - to do that, they will have
 >>> to charge people - if they generate more than a modest amount of traffic
 >>> they will have to co-lo in POPs which means they'll have to rent rack
 >>> space and other facilities - this will quicky mean they rate limit
 >>> themselves at the aggregate level
 >>>
 >>> why use skype anyhow when you can use ichat, marratech and other fine
 >>> tools that allow video, shared whiteboards and have really really nice
 >>> interfaces?
 >>>
 >>> oh, ok, i admit it - skype is pretty cool:)
 >>>
 >>>
 >>> (I am tempted to say that the internet is in fact a shared illusion
 >>> caused by a deficit of information, and that in reality, all those
 >>> pixels lighting up on the screen in front of You<---->Right Now,
 >>> are just fragements of a dream.)
 >>>
 >>> (p.s.  I am even more tempted after recent food scares in the UK to say:
 >>>
 >>> - Additive Increase: just say no.
 >>> - Multiplicative Decrease: its too too devisive.
 >>> - On or off, that should be good enough for the law of large numbers...
 >>> just given a big enough dice.
 >>>
 >>> this is the voice of the mysterons... ... ...
 >>>
 >>> In missive <11ad0fa8050304053342514f51 at mail.gmail.com>, Emmanuel Papirakis
 >>typed:
 >>>
 >>>  >>Hello,
 >>>  >>
 >>>  >>a VoIP application called Skype is gaining more and more popularity. I
 >>>  >>did a basic capture using Ethereal. It seems that it continuously
 >>>  >>sends data at a rate of 10 KB/sec.
 >>>  >>
 >>>  >>Obviously, it does not use a sliding window mechanism nor does it
 >>>  >>consider the rate at  which the receiver is able to receive data.
 >>>  >>Furthermore, it does not attempt to detect periods of silence and
 >>>  >>during those, it continues to send data at its 10KB/sec constant bit
 >>>  >>rate.
 >>>  >>
 >>>  >>A colleague of mine is very enthousiastic about Skype as it saves him
 >>>  >>a lot of money on  his long distance bills. According to his vision of
 >>>  >>Skype, one day, everybody is going to use Skype....
 >>>  >>
 >>>  >>This scares me. Intuitively, this looks like the perfect recipe for a
 >>>  >>congestion collapse. But, he argues that this could not be the case as
 >>>  >>there are miles and miles of unused copper and fiber opticts out there
 >>>  >>and that more bandwidth is widely available across the world...
 >>>  >>
 >>>  >>IMHO, I think that applications like Skype should be responsible for
 >>>  >>managing the congestion they could potentially cause. This brings me
 >>>  >>to my question. If more and more applications start to behave like
 >>>  >>Skype and selfishly worry more about their business model than about
 >>>  >>the health of the global Internet, is there still a possibility of a
 >>>  >>congestion collapse today ? Or, are those worries well behind because
 >>>  >>the problem can be compensated by introducing more bandwidth into the
 >>>  >>network ?
 >>>  >>
 >>>  >>Thank you
 >>>  >>
 >>>  >>Emmanuel
 >>>  >>
 >>>  >>-- 
 >>>  >>UNIX IS very user friendly. It is just selective about its friends...
 >>>
 >>>  cheers
 >>>
 >>>    jon
 >>>
 >>>
 >>
 >>

 cheers

   jon



More information about the end2end-interest mailing list