Previous

Content  

Next

2.3.- PRIO queuing discipline

  

For explaining PRIO queuing discipline Chuck [11] treatment of the issue is again impeccable; just some sentences and a figure:
Priority queuing (PQ) is the basis for a class of queue scheduling algorithms that are designed to provide a relatively simple method of supporting differentiated service classes. In classic PQ, packets are first classified by the system and then placed into different priority queues. Packets are scheduled from the head of a given queue only if all queues of higher priority are empty. Within each of the priority queues, packets are scheduled in FIFO order. (See Figure 2.3.1).
 

 
On Linux things are a little bit complicated. Reading from the man page and Lartc people [7] we can build an explanation. The PRIO qdisc is a classful queuing discipline that contains an arbitrary number of classes of different priority. When a packet is enqueued a sub-qdisc is chosen based on a filter command that you give with tc. When you create a new PRIO queue three pfifo sub-queuing disciplines are created. In fact, automatically 3 classes named m:1, m:2 and m:3 are created where m is the major number of the queuing discipline. Each of these classes is assembled with a pfifo as its own qdisc. A diagram, please, to understand better this stuff!!
 
   

 

Have a look to figure 2.3.2. Whenever a packet needs to be dequeued class :1 is tried first. When it is empty class :2 is tried and finally class :3. As is almost obvious this queue could be really a problem such as it is. Suppose you are implementing a DS-AF architecture and you decide to associate DS classes AF11, AF21 and AF31 with the 3 classes offered by the PRIO qdisc, respectively. Perhaps you were lucky and things work at all. But, left your mind flying: what happen if a scenario appears where departure rate is less than arrival rate due to some congestion problem in the output link? And at the same time AF11 flows' arrival rate is higher than the departure rate. In this case always you will have AF11 packets waiting in the class :1 queue and classes :2 and :3 will not be served.
AF21 and AF31 customers are going to call you really very angry with you: hey, guy, what's going on there? This problem can be fixed changing the class :1 pfifo qdisc for some type of qdisc that put an upper level to AF11 flows. For example a TBF qdisc. Have a look to a Werner's diagram somewhere above for an example of this issue.
As you probably deduced this qdisc, when configuring with care, can be very useful in case you want to prioritize certain kind of traffic in favor of other. Let's see now how to manage this pet with tc. But first a fast trip over the parameters. Reading from Lartc [7] we have:
The following parameters are recognized by tc:
 bands
  Number of bands to create. Each band is in fact a class. If you change this number, you should
probably also change the priomap.
 priomap
  "If you do not provide tc filters to classify traffic", the PRIO qdisc looks at the TC_PRIO
priority to decide how to enqueue traffic. The kernel assigns each packet a TC_PRIO priority,
based on TOS flags or socket options passed by the application.
  The TC_PRIO is decided based on the TOS, and mapped as follows:
 

The bands are classes, and are called major:1 to major:3 by default, so if your PRIO qdisc is called 12:, tc filter traffic to 12:1 (band 0) to grant it more priority. Reiterating, band 0 goes to minor number 1, band 1 to minor number 2, etc.
Well, nice but not too much, for our goal at least. 'priomap' parameter tells us that for using PRIO queuing discipline we have to provide filters because default behavior is not for us. Why? Protecting TOS (Why?) we will show PRIO qdisc setup using filters:

We know this command already. However, this time we are numbering our PRIO qdisc ourselve as 1:0 (the zero can be avoided when working with tc). Because PRIO is some sort of automatic queue this command instantly create classes 1:1, 1:2 and 1:3 and each of them has its pfifo queue already installed.
Let's see how to implement the filters. We will insist in our original idea, this means, to assign AF classes AF11, AF21 and AF31 to prio classes 1:1, 1:2 and 1:3. Do you remember our tip rule to compose codepoints? Using it we have:
  AF11 = 1-2 = 001010
AF21 = 2-2 = 010010
AF31 = 3-2 = 011010
These are the six leftmost bits (DS-codepoint); the complete TOS byte will have two zero-bit to the right. Finally we have:
  AF11 = 00101000 = 0x28
AF21 = 01001000 = 0x48
AF31 = 01101000 = 0x68
Last hexadecimal number is what we will use to buid our filters. First, the first of them:

Oh, my god. Let's try to decipher this. 'tc filter add dev eth0' is less than obvious: "hey, tc, add a filter on device eth0, thanks!". 'parent 1:0' means "the parent of the filter is going to be the object identify with the number 1:0 that happens to be our PRIO qdisc". 'prio 1' means "try this filter with priority 1"; if happens to be some other filter with prio 2, 3, 4, etc., try them in this order. 'protocol ip' means "we are working with the ip protocol". 'u32' means "our filter is just an u32 filter"; is just a type. There are other types as fwmark, route, etc. but we are not interested on them now. 'match ip' means "what follows has to be matched against the ip header of the packet". 'tos 0x28 0xff' means "match exactly tos byte 0x28". tc always multiplies the first term with the second one to get the number to be matched: 0x28 * 0xff is just 0x28. Using 0xf0, for example, we can change the matching number. Finally 'flowid 1:1' means "flows matching this filter have to be sent, directly, to the class identify with number 1:1"; this happens to be our PRIO 1:1 class.
Easy. Isn't it? Now let's write the next two commands:
 

 
Eureka!! After this we have assembled our prio qdisc represented in the figure above. Congratulations.
 
But, as we saw previously when studying FIFO, PRIO has its benefits and problems too (who doesn't have?). Again, Chuck [11] approach is clear and very complete:
 
PQ offers a couple of benefits:
 
  • For software苑ased routers, PQ places a relatively low computational load on the system when compared with more elaborate queuing disciplines.
     
  • PQ allows routers to organize buffered packets, and then service one class of traffic differently from other classes of traffic. For example, you can set priorities so that real負ime applications, such as interactive voice and video, get priority over applications that do not operate in real time.
But PQ also results in several limitations:
 
  • If the amount of high計riority traffic is not policed or conditioned at the edges of the network, lower計riority traffic may experience excessive delay as it waits for unbounded higher計riority traffic to be serviced.
     
  • If the volume of higher計riority traffic becomes excessive, lower計riority traffic can be dropped as the buffer space allocated to low計riority queues starts to overflow. If this occurs, it is possible that the combination of packet dropping, increased latency, and packet retransmission by host systems can ultimately lead to complete resource starvation for lower計riority traffic. Strict PQ can create a network environment where a reduction in the quality of service delivered to the highest計riority service is delayed until the entire network is devoted to processing only the highest計riority service class.
 
   

 
  • A misbehaving high計riority flow can add significantly to the amount of delay and jitter experienced by other high計riority flows sharing the same queue.
     
  • PQ is not a solution to overcome the limitation of FIFO queuing where UDP flows are favored over TCP flows during periods of congestion. If you attempt to use PQ to place TCP flows into a higher計riority queue than UDP flows, TCP window management and flow control mechanisms will attempt to consume all of the available bandwidth on the output port, thus starving your lower計riority UDP flows.
It is very important to know the advantages and disadvantages of each qdisc to have better decisions when applying them. There is a nice guy, Stef Coene at www.docum.org, that has carried this bag in Linux since a long time. Have a look to his site. There is a lot of useful information on there. To continue our next queuing discipline will be TBF.
   

Previous

Content  

Next