Re: [LARTC] PRIO / CBQ / HTB queue drop algorithm

[Andy Furniss <andy.furniss@dsl.pipex.com>]

rsenykoff@harrislogic.com wrote:
> Hello all.
> 
> I've been struggling to QoS VoIP at our site and have a successful 
> implementation at this point. Basically I had to set aside enough 
> bandwidth for VoIP by placing all other traffic behind an HTB (multiple 
> classes and queues behind it). Everything is fine. Here's the diagram:
> 
>          -------
>          | eth |
>          -------
>             |
>          --------
>          | PRIO |
>          --------
>        /          \
>     1/             2\
> ---------             \
> | PFIFO |       ---------------------
> | VoIP  |       | Hier. Token Bucket | <-- throttled so it + VoIP won't 
> overrun
> ---------       ----------------------     the ethernet link (we know how 
> many
>               /     2|        3|       \   phones we have so this is 
> possible
>            1/    --------- ---------    4\ until you get into conferencing 
> etc)
>       ---------  | PFIFO | | PFIFO |   --------- 
>       | PFIFO |  | video | | inst. |   | fair  |
>       |citrix |  --------- | msgr  |   | SFQ   | 
>       ---------            ---------   | bulk  |
>                                        ---------
> 
> I tried using CBQ and HTB as the higher level queues, but it seems that 
> with lending of traffic out, there is a delay (waiting for space in the 
> queue) where packets from VoIP will get dropped until there's space. I'm 
> guessing that the queues all use a basic tail-drop algorithm.
> 
> Have I been doing something wrong? It sure would be cool to be able to 
> provide immediate bandwidth to VoIP (and other interactive applications) 
> while still letting those interactive traffic  classes lend out bandwidth. 
> For example, an option on PRIO that lets you specify random drop, and what 
> bands to drop from. Thus, if a VoIP packet arrives and the queue is full, 
> rather than dropping the VoIP packet, randomly drop a packet from the bulk 
> traffic band of the PRIO queue.
> 
> Any thoughts on this are very welcome. 
> 
> TIA!
> -Ron S.

HFSC may be the best solution, but there aren't many examples/much 
support for it yet.

You can lend out unused interactive bandwidth with HTB and keep latency 
low, the trick is to give interactive class much more bandwidth (rate) 
than it needs and make bulk classes have low rates. Give interactive 
prio 0 which is highest priority.

Andy.



_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/