[e2e] very simple IP QoS for the bottleneck access link ?

[Marc Herbert]

On Tue, 5 Apr 2005, Sireen Habib Malik wrote:

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

> It is to be noted that if an MPLS type of tunnel is used...

Now I am not sure I made myself clear... I am talking about a very
simple solution _local_, _private_ to the access link, and to solve
only the bottleneck issue at the access link. You get what you paid
for. But it could still be very interesting IMHO.

So no tunnels, no routers involved at all.

Concerning VoIP for instance, each end would have to implement this
trick on its own access link _independently_ from the other end. If
only one end does, well only this end can abuse its access link with
P2P traffic while phoning simultaneously. The other end has to stop
eMule as usual.


-- 
So einfach wie möglich. Aber nicht einfacher -- Albert Einstein