[e2e] very simple IP QoS for the bottleneck access link ? (was Skype and congestion collapse.)

[Sireen Habib Malik]

Marc Herbert wrote:

>The implementation looks simple. The latency-sensitive application
>regularly sends to both access link halves (up- and down- stream) some
>way to identify their packets (for instance: dst UDP port 27015
>belongs to higher class). The access link implement strict priority
>for those latency-sensitive packets.  Elastic traffic takes the rest.
>Only two traffic classes, can be implemented cheaply by a DSLAM and by
>a consumer device. No complex configurations. For those customers who
>only have a poor USB DSL modem, this could be implemented in the PC
>itself.
>
>  
>
Here is my understanding of how it is done today. End node marks Layer-2 
CoS and/or Layer-3 DSCP fields of the IP/UDP/RTP/Voice packet.
Voice traffic is given the top priority and is sent into a Priority 
Queue (PPQ). The low priority queue could be RED or Weighted-RED, WFQ, etc.

In order for this to work, the end must be in the "trust" region i.e 
CoS/DSCP fields should not be reset by the downstream routers/switches 
in the path.

The presence of the other, lower priority, queue adds to the 
"variations" of the departing voice trafic from the PQ. Studies have 
shown that packet delay for this type of queue can be well bounded with 
M/D/1 delay + residual time of the lower priority packets.  It is to be 
noted that if an MPLS type of tunnel is used for "voice only" then delay 
is modeled with SUM(D) /D/1 type of system which has significantly lower 
mean packet delay. So there are trade-offs.

Please note, QoS for VoIP is an "Mouth-To-Ear" issue so many other 
factors get involved.
--
SM













>Since it's local it's scalable. No need to perform QoS at lightning
>speed, the load is spreaded to numerous network ends, etc.
>
>Since it's local it's incremental. It's incremental in the sense you
>can deploy it for one customer and not the other without any issue.
>It's incremental in the sense some ISP can start offering it without
>caring about the others ISP. It's incremental in the sense you can
>deploy it for some applications and not the others _on the same access
>link_. Legacy applications just get the lower class. It's incremental
>in the sense you can deploy it first for the upstream access link (the
>biggest issue today because of the "A" in ADSL)  before the downstream
>link.
>
>It's also incremental in the sense you can make it peacefully co-exist
>with a more primitive and less reliable "guess well-known UDP ports"
>approach. It's incremental in the sense that, once started,
>applications will have a strong incentive to move to this API.
>
>What about the user registering too much traffic in the upper priority
>class?  Well, it fails. Not worst than today. Most internet users now
>know how to solve this congestion issue (observed immediately): they
>shut some applications down. No computations, the simple try and fix
>approach known today, only better. The only added complexity is the
>two classes. Since most elastic applications report the currently used
>throughput, users would not have a hard time understanding that
>shutting down an application that is left with zero kb/s will not
>solve their congestion issue in this case.
>
>Since it's local I hardly see any security issue. Well you can imagine
>some rogue application running in your home and stealing bandwith, but
>then I would say you have a much bigger issue anyway.
>
>>From the point of view of the end to end argument, you can think of it
>as the definition of "the end" has been extended to include the access
>link. Is this too much heretical? IMHO there have been much worst
>deviances from The Argument in network history (firewalls anyone?).
>
>Do you think it could have any economical viability? I think that if
>just one ISP and one CBR killer app (Skype, a game, whatever) would
>start to package it then it would sell. "No more lag thanks to our
>brand new low-ping advanced technology. Now you can download and play
>at the same time". You can even give to power users an advanced link
>access controller allowing them to prioritize most legacy applications
>and widening the market potential, attracting all geeks.
>
>Any issues I missed ?  There must be some. This looks too good to
>be true :-) Thanks a lot in advance for your comments.
>
>
>
>  
>


-- 

Sireen Malik, M.Sc.
PhD. Candidate,

Communication Networks
Hamburg University of  Technology,
FSP 4-06 (room 3008)
Denickestr. 17
21073 Hamburg, Deutschland

Tel: +49 (40) 42-878-3387
Fax: +49 (40) 42-878-2941
E-Mail: s.malik at tuhh.de

--Everything should be as simple as possible, but no simpler (Albert Einstein)