[e2e] Skype and congestion collapse.

[DJamel H. Sadok]

I think that it is still worth making a large number of mice happy and
maybe one unhappy elephant.

The current Internet approach of one size fits all probably cannot be 
extended to corporate practices. Maybe future Internet architectures 
should not only consider technology diversity (mobile networks, sensor 
networks, etc...), naming problems, DNS limitations but also policy 
differences. We could see a future Internet made from various "what some 
people called contexts [work from Jon]". One of these could be the 
corporate context.

Djamel


On Mon, 7 Mar 2005, Cannara wrote:

> The points of interest to people (corporate) wanting to limit P2P, IM and even
> VoIP, are at least:
>
> a) Intellectual property theft/dispersal.
>
> b) Liability to copyright suit.
>
> c) Hidden file accesses (perhaps for a & b).
>
> d) WAN-link capacity reduction.
>
> Note that knowing how much of any given traffic is occurring among points
> within and outside an organization also suggests what might be going on.
> Just pure phone calling is typically not the concern.  Any protocol may be
> misused by an application designed to masquerade as benign.  Traffic stats
> help uncover such piracy.  Also, while there are P2P sources that are limited,
> many universities have high-rate links to the Inet, so keeping all the
> students at bay in up/downloading is important in many such places, not just
> corporations.  A couple of friends who manage parts of Stanford's net
> explained what happened one day when a Packeteer box failed and a dorm or two
> were no longer limited to 100Mb/s into the 1Gb/s path.  :]
>
> Alex
>
> "DJamel H. Sadok" 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 P2P multimedia transfers. Even when many instances of
>> voice sessions for example are made at the access network/loop. If this is
>> not going to be a problem at thi side of the network, it can hardly cause
>> problems within overprovisioned backbones.
>>
>> Most P2P heavy applications are end-to-end (generated by residential
>> users) and therefore would not be capable of occupying high bandwidth
>> (Mbps! any numbers to counter this!!) network share although they often
>> transfer large amounts of data.
>>
>> 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.
>>
>> P2P applications allow a user to specify her uplink and downlink bandwidth
>> capacities. That is more that is needed in terms of congestion control of
>> course when using the underlying TCP.
>>
>> Djamel
>>
>>   On Fri, 4 Mar 2005, Cannara wrote:
>>
>>> Having consulted with folks doing products for tracking/controlling these
>>> kinds of traffic, any P2P system that takes whatever it can isn't really to
>>> blame.  Even VoIP is being used to transfer data (not just voice) now.  Any
>>> 'internet' that can't manage its congestion at the network layer isn't an
>>> internetwork.  So, apart from all the other Internet mistakes, like
>>> insecurity, which many of us earn $ from, we've also earned from misdesigned
>>> congestion control.  The difference between old-fashioned PSTNs and the
>>> Internet are making the latter look more silly and wasteful day by day.
>>> Despite the $, I hope some awakening occurs, but we, the taxpayers, will again
>>> have to pay for any eventual, engineered and real internetwork.
>>>
>>> Alex
>>>
>>> "Alexandre L. Grojsgold" wrote:
>>>>
>>>>> 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,
>>>>
>>>> I guess that what you mean is that Skipe does not use TCP-like bandwidth
>>>> reduction, so it selfishly does not give up sending 10Kbps even in case of
>>>> congestion.
>>>>
>>>> Well, one must have in mind that at the end of a skype voice connection
>>>> ther is as human being that, in case of congestion and excessive packet
>>>> loss will simply hang up the call - or even be so unhappy that he will
>>>> never try calling thru Skype again.
>>>>
>>>> Probably the "selfish" behavior if skipe is due to the fact that it is
>>>> unable to make voice go thru using less than 10k - lessening the bandwidth
>>>> would be useless, so in case of congestion, it will simply hang up - or
>>>> wait till the user gives up.
>>>>
>>>> -- Alexandre.
>>>
>