[e2e] Skype and congestion collapse.

Richard Wade rik at rikwade.com
Mon Mar 7 11:54:26 PST 2005


"DJamel H. Sadok" <jamel at cin.ufpe.br> wrote:
> IMHO, it does not anymore make a lot of sense to penalyze "low" bandwidth
> applications such as skype/voip/.. by applying TCP-like congestion control
> or access control schemes. Such mechanisms are better used on heavy
> hitters such as some P2P multimedia transfers.

But how many mice does it take to bring down an elephant?
This area has been examined quite extensively. A quick Web search revealed:

http://www.ieee-infocom.org/2004/Papers/58_2.PDF "Using Partial
Differential Equations to Model TCP Mice and Elephants in Large IP
Networks"

or for a different view of the problem:

http://www.caida.org/outreach/papers/2002/Dragonflies/cnit.pdf
"Understanding Internet Traffic Streams: Dragonflies and Tortoises"

>From a practical IP networking perspective, the "big hitters" are actually
quite easy to deal with. If you've got a flow that's long in duration
(minutes, hours, or days) then policy can be applied at the edge of your
network to shape or control it. Many people are having to deploy P2P
control systems in their networks due to the huge increase in this type of
application over the past few years.

In the late 1990s, people deployed huge arrays of HTTP proxies in order to
save on expensive off-net bandwidth. The effectiveness of this slowly
decreased as more and more dynamic content was served up. P2P is just the
latest application type that is consuming the majority of off-net transit
for service providers. Yes, bandwidth costs are much lower than in the
late 1990s, but you still want to minimise the cost, right?

You can deploy P2P caches on-net, but some people seem to be shying away
from deploying them, citing "legal reasons". I'm not quite sure what the
difference is between a P2P cache and a HTTP cache in this respect,
however. Alternatively, you can use protocol re-write engines, such as the
Packeteer, which can sit in-line and shape the flows down to specified
rates. Or you can try to just queue and shape the application's traffic at
your edge routers.

> We need traffic to justify giga-networks hopefully all the way to the
> local loop. There has been a great deal of work on protocol adaptation and
> congestion control with little actual use.

I would actually argue that we need the applications to justify
giga-networks, not just "traffic". What actually _are_ the killer
applications for high bandwidth consumer access? VoIP? - low bandwidth;
Web? - low bandwidth and non-realtime; etc. So we're currently left with
P2P file transfer which, among its many legitimate uses, is generally used
to illegally distribute copyright material. Not quite the ideal "killer
application".

Arguably, many providers are building high bandwidth access (and core)
networks to support next-generation services which aren't quite here yet.
Before these services can be deployed and the networks can be engineered
in to a state that permits more fine-grained traffic control, applications
such as Skype will have to deal with this type of situation.
--
rik



More information about the end2end-interest mailing list