PRIO / CBQ / HTB queue drop algorithm

[rsenykoff@xxxxxxxxxxxxxxx]

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.