LARTC - Jun 2006 - Sanity Check

Hi all.

I need a sanity check.  I''m trying to setup my network to handle VoIP. 
I''m
thinking that all I need to do is prioritize the realtime traffic above the 
interactive and bulk traffic.  I see so much discussion about traffic 
shapping, but I don''t THINK this is needed, right?  I understand the
problem
with bandwidth starvation, but for my application, the voip traffic has to 
get out at whatever cost.

Am I missing anything?

Thanx for your time.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Good morning, Mike,

 : I need a sanity check.  I''m trying to setup my network to handle 
 : VoIP.  I''m thinking that all I need to do is prioritize the 
 : realtime traffic above the interactive and bulk traffic.  I see 
 : so much discussion about traffic shapping, but I don''t THINK this 
 : is needed, right?  I understand the problem with bandwidth 
 : starvation, but for my application, the voip traffic has to get 
 : out at whatever cost.

In fact, you will need shaping, but you may be able to use a 
combination of an HTB class (to address the shaping) and a contained 
prio qdisc to handle your VoIP traffic.

I''m going to assume for the remainder of my answer that you are
talking about a leaf network, so you have Internet access through a
single provider over some sort of broadband connection and you have
a handful of potential VoIP and bulk Internet traffic inside that
leaf network.

  Q: Why can''t I just use a prio qdisc to handle my VoIP traffic?
  
  A: VoIP traffic is sensitive to latency and jitter.  Without some
     sort of limitation on the total amount of traffic you push
     through your Internet pipe, even a single bulk upload or
     download can affect the latency and jitter of traffic
     transmitted or received.
  
     Let''s say you have a 768 down/256 up (kbit) link, now, assume 
     that somebody builds a connection into or out of your network 
     and pushes data as fast as possible out of the network.  With a 
     prio qdisc, your outbound VoIP packets will indeed always be 
     transmitted first, but the queue is outside your control.  
     This queueing may be happening on an upstream router or bridge.

That''s a problem for your VoIP call, because you do not have control 
over delay or jitter.  The above is a verbose explanation of one of 
the rules of traffic control.  Make sure that your machine is the 
bottleneck.

So, instead of trying to use a prio qdisc alone, try using a single 
HTB class to limit your traffic to a given rate and then embed your 
prio qdisc inside that.  There are many other possible options for 
nested qdiscs, and maybe somebody on this list will make a 
recommendation to you for how s/he solved this problem.

- -Martin

- -- 
Martin A. Brown
linux-ip.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: For info see quantumlab.net/pine_privacy_guard

iD8DBQFEn+7Wki79Zb8hnmwRAvH+AJ9smcUUXr/Ly8f1MaGsxjSsAX7gJgCfSb+C
ENDJX7a5RWRgaK+WMY0Q3u0=PH0T
-----END PGP SIGNATURE-----

Martin,

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.

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?

Thanx again for your time

On Monday 26 June 2006 08:27, Martin A. Brown wrote:
> Good morning, Mike,
>
>  : I need a sanity check.  I''m trying to setup my network to
handle
>  : VoIP.  I''m thinking that all I need to do is prioritize the
>  : realtime traffic above the interactive and bulk traffic.  I see
>  : so much discussion about traffic shapping, but I don''t THINK
this
>  : is needed, right?  I understand the problem with bandwidth
>  : starvation, but for my application, the voip traffic has to get
>  : out at whatever cost.
>
> In fact, you will need shaping, but you may be able to use a
> combination of an HTB class (to address the shaping) and a contained
> prio qdisc to handle your VoIP traffic.
>
> I''m going to assume for the remainder of my answer that you are
> talking about a leaf network, so you have Internet access through a
> single provider over some sort of broadband connection and you have
> a handful of potential VoIP and bulk Internet traffic inside that
> leaf network.
>
>   Q: Why can''t I just use a prio qdisc to handle my VoIP traffic?
>
>   A: VoIP traffic is sensitive to latency and jitter.  Without some
>      sort of limitation on the total amount of traffic you push
>      through your Internet pipe, even a single bulk upload or
>      download can affect the latency and jitter of traffic
>      transmitted or received.
>
>      Let''s say you have a 768 down/256 up (kbit) link, now, assume
>      that somebody builds a connection into or out of your network
>      and pushes data as fast as possible out of the network.  With a
>      prio qdisc, your outbound VoIP packets will indeed always be
>      transmitted first, but the queue is outside your control.
>      This queueing may be happening on an upstream router or bridge.
>
> That''s a problem for your VoIP call, because you do not have
control
> over delay or jitter.  The above is a verbose explanation of one of
> the rules of traffic control.  Make sure that your machine is the
> bottleneck.
>
> So, instead of trying to use a prio qdisc alone, try using a single
> HTB class to limit your traffic to a given rate and then embed your
> prio qdisc inside that.  There are many other possible options for
> nested qdiscs, and maybe somebody on this list will make a
> recommendation to you for how s/he solved this problem.
>
> -Martin

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
linux-ip.net

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all,

 : So, instead of trying to use a prio qdisc alone, try using a 
 : single HTB class to limit your traffic to a given rate and then 
 : embed your prio qdisc inside that.  There are many other possible 
 : options for nested qdiscs, and maybe somebody on this list will 
 : make a recommendation to you for how s/he solved this problem.

This is a correction/clarification for posterity.  There is still a 
problem with the above, and I''d like to correct it and thank Gustavo 
Homem [0] for pointing out my possibly misleading advice here.

Mike indicated that he was willing to let VoIP traffic out 
regardless of the cost to other flows.  This means that the above 
solution might work acceptably for his needs in this situation...

However, this is not a good general solution!

When evaluating a traffic control mechanism for a particular 
solution, there are a number of different network characteristics 
that we need to keep in mind.  The big three are throughput, delay 
and jitter.

Each traffic control mechanism that we might employ affects at least 
one (and almost always more than one) of the above network 
characteristics.  Selecting the correct mechanism for a given 
application depends on what we are willing to trade.

Some people are willing to trade total throughput for delay (those 
of us who like responsive ssh sessions, for example).

Some people MUST trade delay and jitter for throughput (VoIP 
applications).

So, to return to the problem of a single PRIO qdisc (a 
work-conserving queuing discipline), how can we add some sort of 
non-work-conserving mechanism (shaping) and still take advantage of 
some prioritization.

There are a number of ways to solve this problem, but let''s look at 
the following options (+ = good, - = not-so-good):

  A. HTB qdisc, one class, with child PRIO qdisc

     + HTB shapes total dequeued traffic rate to the specified 
       maximum rate.
     + PRIO qdisc ensures that traffic you classify as high 
       priority always has preferential access to full link 
       bandwidth (as limited by HTB''s rate)
     - high priority flows can completely starve low priority
       flows

  B. PRIO qdisc, each class contains a TBF qdisc specifying 
     transmisison rate

     + each class gets up to its TBF of throughput before it gets 
       shaped.
     + each class gets is completely isolated from the other classes
       so if the sum of the rates of the TBF qdiscs does not exceed
       link bandwidth, you should see predictable delay and jitter
     - any given class could become backlogged easily and there''s
       no sharing between classes

  C. HTB qdisc, HTB children classes[, children sfq or fifo qdiscs]

     + HTB shapes total dequeued traffic rate to the specified 
       maximum rate.
     + HTB children classes can borrow from parent classes, if 
       some bandwidth goes unused
     - must write filters to specify which class receives which 
       packets

The above is just an outline to point out some of the tradeoffs that 
need to be examined and understood when choosing a traffic control 
mechanism for any particular situation.

I was probably a bit facile in my answer to Mike, so I hope this 
post clears up the ambiguity of the recommendation.

Good luck and happy QoS!

- -Martin

 [0] mailman.ds9a.nl/pipermail/lartc/2006q3/019232.html

- -- 
Martin A. Brown
linux-ip.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: pgf-0.71 (linux-ip.net/sw/pine-gpg-filter)

iD8DBQFEsxDdHEoZD1iZ+YcRAormAJsGkouYrqoM0q8Zgw0aCaXpZTMKkQCfbc+E
UruTl/GvAVMHqGRqzUwwc0Q=Sk64
-----END PGP SIGNATURE-----