* [LARTC] PRIO / CBQ / HTB queue drop algorithm
@ 2005-02-02 23:12 rsenykoff
2005-02-08 1:34 ` Andy Furniss
0 siblings, 1 reply; 2+ messages in thread
From: rsenykoff @ 2005-02-02 23:12 UTC (permalink / raw)
To: lartc
This is a multipart message in MIME format.
--=_alternative 007F7DF186256F9C_Content-Type: text/plain; charset="US-ASCII"
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.
--=_alternative 007F7DF186256F9C_Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">Hello all.</font>
<br>
<br><font size=2 face="sans-serif">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:</font>
<br>
<br><font size=2 face="Courier New"> -------</font>
<br><font size=2 face="Courier New"> |
eth |</font>
<br><font size=2 face="Courier New"> -------</font>
<br><font size=2 face="Courier New">
|</font>
<br><font size=2 face="Courier New"> --------</font>
<br><font size=2 face="Courier New"> |
PRIO |</font>
<br><font size=2 face="Courier New"> --------</font>
<br><font size=2 face="Courier New"> /
\</font>
<br><font size=2 face="Courier New"> 1/
2\</font>
<br><font size=2 face="Courier New">---------
\</font>
<br><font size=2 face="Courier New">| PFIFO | ---------------------</font>
<br><font size=2 face="Courier New">| VoIP |
| Hier. Token Bucket | <-- throttled so it + VoIP won't overrun</font>
<br><font size=2 face="Courier New">--------- ----------------------
the ethernet link (we know how many</font>
<br><font size=2 face="Courier New">
/ 2| 3|
\ phones we have so this is possible</font>
<br><font size=2 face="Courier New">
1/ --------- --------- 4\ until you get
into conferencing etc)</font>
<br><font size=2 face="Courier New"> --------- |
PFIFO | | PFIFO | --------- </font>
<br><font size=2 face="Courier New"> | PFIFO | |
video | | inst. | | fair |</font>
<br><font size=2 face="Courier New"> |citrix | ---------
| msgr | | SFQ | </font>
<br><font size=2 face="Courier New"> ---------
--------- | bulk |</font>
<br><font size=2 face="Courier New">
---------</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">Any thoughts on this are very welcome.
</font>
<br>
<br><font size=2 face="sans-serif">TIA!</font>
<br><font size=2 face="sans-serif">-Ron S.</font>
<br>
<br>
<br>
--=_alternative 007F7DF186256F9C_=--
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: [LARTC] PRIO / CBQ / HTB queue drop algorithm
2005-02-02 23:12 [LARTC] PRIO / CBQ / HTB queue drop algorithm rsenykoff
@ 2005-02-08 1:34 ` Andy Furniss
0 siblings, 0 replies; 2+ messages in thread
From: Andy Furniss @ 2005-02-08 1:34 UTC (permalink / raw)
To: lartc
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/
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2005-02-08 1:34 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-02-02 23:12 [LARTC] PRIO / CBQ / HTB queue drop algorithm rsenykoff
2005-02-08 1:34 ` Andy Furniss
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.