Re: VoIP using just prio qdisc? No. was [ Sanity Check ]

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----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] http://mailman.ds9a.nl/pipermail/lartc/2006q3/019232.html

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

iD8DBQFEsxDdHEoZD1iZ+YcRAormAJsGkouYrqoM0q8Zgw0aCaXpZTMKkQCfbc+E
UruTl/GvAVMHqGRqzUwwc0Q=
=Sk64
-----END PGP SIGNATURE-----
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux