Mike,
: I'm not trying to be obstinate, I'm just trying to understand
: this more fully. But I sure appreciate the time you spent
: answering my question.
:
: But, I'm still missing something.
No worries--that's what mailing lists are for. A bit of back and
forth.
: You mention below that during a VoIP session, another user could
: start up a large, high bandwidth, transfer and that this will
: affect the queueing... If the VoIP traffic always gets out the
: door first, how can this affect the jitter and latency of the
: VoIP session; I understand it may devistate the other transfer...
: Is this what you are trying to avoid by using HTB?
Different flows expect different behaviour from the network. Bulk
flows generally expect high throughput. Media applications
frequently expect low delay and low jitter from the network.
Here's the question I think you might be missing:
Where are the queues building up?
To make this as concrete as possible, I want to talk about about
only one half of our VoIP session. I want to talk about the flows
outbound from your network. Think of this as upload traffic. Let's
assume:
1. V = VoIP client (inside your network)
2. R = VoIP receiver (outside)
3. F = bulk upload client (inside your network, greedy!)
4. L = Linux router
5. 256 kbit max upload speed
Here's what we're watching. Remember that your prio qdisc will
always prefer to transmit the VoIP packets first. Here's what's
happening on your Linux router:
- V establishes 64kbit flow with R
- F starts sending as fast as possible
- L always transmits (dequeues) packets from V's flow first,
but will transmit packets from F's flow as fast as it can
- somewhere upstream at the choke point, a router or bridge will
see increasing queue depths as a result of F's flows
- the variable queue depth on this upstream device will mean that
V's packets will see increased delay and much higher jitter*
So, yes, you can use a prio qdisc on the Linux router, but it
doesn't really solve the problem for you. The Linux router may
always dequeue your VoIP packets before it dequeues the packets of
your other flows. Assuming the device through which you are
transmitting is an Ethernet card, the Linux router can dequeue
packets at a much higher rate than your link to the net can
accommodate. Thus, you need to use shaping to control the total
flow rate transmitted by the router.
It is for this reason that one of the key rules of traffic control
is for you to ensure that your host is the bottleneck.
I hope that does a better job of explaining the problem, Mike.
Volley!
-Martin
* VoIP is really sensitive to delay and somewhat sensitive to
jitter.
--
Martin A. Brown
http://linux-ip.net/
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
