Re: VoIP using just prio qdisc? No. was [ [LARTC] Sanity Check ]
-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@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: VoIP using just prio qdisc? No. was [ [LARTC] Sanity Check ]
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@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
VoIP using just prio qdisc? No. was [ [LARTC] Sanity Check ]
-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 http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQFEn+7Wki79Zb8hnmwRAvH+AJ9smcUUXr/Ly8f1MaGsxjSsAX7gJgCfSb+C ENDJX7a5RWRgaK+WMY0Q3u0= =PH0T -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: VoIP using just prio qdisc? No. was [ [LARTC] Sanity Check ]
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 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
