Previous

Content

Next 

2.4.2.3 Custom queuing discipline  

Custom queuing discipline (CQ) reserves a percentage of an interface's available bandwidth for each selected traffic type. If a particular type of traffic is not using its shared bandwidth, then other type may use this availability. CQ is composed of 17 queues numbered from 0 to 16. Queue 0 is a system queue reserved for the mechanism and therefore can not be set by the user. Queues 1 to 16 are the setable queues.
Idea behinds CQ is to assign a percentage of the available bandwidth to each of the 16 queues until reaching the 100% of total availability. Let's steal next figure from Cisco that explains better than a hundred words; I added some color for better understanding. Have a look to figure #7 below.

It looks like very easy. The queues are served in a weighted round-robin scheme. Weighted because depending of the weight (% of share) the available bandwidth is distributed among queues. I say, 'looks like very easy' because in fact, as all Cisco configuration commands, implementation is really confuse. 
First problem is that you can't use percentage shares to set the queues but instead 'byte-count'; and 'byte-count' values are dependent of flow's packet size on the queue. Another problem is classification. You can classify for almost everything (protocol, source interface, source and destination addresses and ports) but if you need to control by address it is then necessary to create in advance the access lists and later on, to assign it to the scheme.
The CQ scheme is identify numerically by something called 'custom-queue-list', very similar to 'priority-list' we talked about above when studying PQ. After creating and populating the scheme you assign it to the interface you want to implement it to. Well, an example is better to understand all this stuff.

A very similar scenario we had before with PQ. This time we have a DNS (Domain Name Service) server too. Our goal is to distribute bandwidth according to this table:

Here we have the percentage shares from available bandwidth and the method we will be using to identify flows from different servers. This distribution is somewhat academic because probably some shares are too much for some of these servers. Anyway to go ahead let's advance by steps:
  1. Consult Cisco to understand CQ behavior.
  2. Calculate byte count for each server.
  3. Create the access list for address selectable flows.
  4. Create the queue-lists.
  5. Assign flows to queues.
  6. Assign the CQ to the interface.
  

1. Consult Cisco to understand CQ behavior 
Reading from Cisco they say: 
"In order to allocate bandwidth to different queues, you must specify the byte count for each queue. The router sends packets from a particular queue until the byte count is exceeded. Once the byte count value is exceeded, the packet that is currently being transmitted will be completely sent. Therefore, if you set the byte count to 100 bytes and the packet size of your protocol is 1024 bytes, then every time this queue is serviced, 1024 bytes will be sent, not 100 bytes. For example, suppose one protocol has 500-byte packets, another has 300-byte packets, and a third has 100-byte packets. If you want to split the bandwidth evenly across all three protocols, you might choose to specify byte counts of 200, 200, and 200 for each queue. However, this configuration does not result in 33/33/33 ratio. When the router services the first queue, it sends a single 500-byte packet; when it services the second queue, it sends a 300-byte packet; and when it services the third queue, it sends two 100-byte packets. The effective ratio is 50/30/20. Thus, setting the byte count too low can result in an unintended bandwidth allocation. However, very large byte counts will produce a "jerky" distribution. That is, if you assign 10 KB, 10 KB, and 10 KB to three queues in the example given, each protocol is serviced promptly when its queue is the one being serviced, but it may be a long time before the queue is serviced again. A better solution is to specify 500-byte, 600-byte, and 500-byte counts for the queue. This configuration results in a ratio of 31/38/31, which may be acceptable."
Well, we have some problems here. First, it is less than obvious that using CQ we will get some aproximation to what we want because the algorithm doesn't have enough precision. But we can live with this. Worst is that we have to estimate flow's packet size in advance. This is not an easy task. For our scenario WWW and DNS packet size is variable. For MAIL it will depend on protocol (smtp, pop, etc.) and then we have to assume them as variable. FTP tries to move bulk data and their packets will be as large as possible; perhaps 4 KB is not uncommon. But because nothing is really sure, FTP implementation will select its own packet size almost surely. I have read somewhere that MS SQL Server (and Sybase too) are 4 KB size. But, what about some other implementations?
And last, but not least, final maximum actual packet size will depend of layer-2 medium. For Ethernet maximum packet size is 1500 bytes. Then each end will negotiate the maximum packet size (MTU) with the other end depending on infrastructure being used. Conclusion: nobody know what people from Cisco was thinking when they designed CQ. And we are not considering some other protocols, like IPX, Appletalk, SNA, DecNet, etc., just TCP/IP. Perhaps the problem is that CQ is an old queuing discipline, but let's go ahead with it.
2. Calculate byte count for each server
Because packets are of different size is better to run with the 'jerky' distribution risk than with a poor share distribution. Then we will assume a maximum 4 KB packet size and entrust to God. This way for each server the byte count selected will be:
SQL server =    3 x 4096 = 12288 bytes
WWW server =    2 x 4096 = 8192 bytes
MAIL server =    1.5 x 4096 = 6144 bytes
FTP server =    1.5 x 4096 = 6144 bytes
DNS server =    1 x 4096 = 4096 bytes
Other =    1 x 4096 = 4096 bytes
3. Create the access list for address selectable flows
These are the SQL, MAIL and FTP servers. This is an easy task, then:

This way ACL 10, 20 and 30 will correspond to SQL, MAIL and FTP servers respectively.
4. Create the queue-lists
We need 6 queues for our 5 servers and rest of the flows, then we have:

CQ is numbered with number 1. We will use 6 of its 16 configurable queues
5. Assign flows to queues
SQL, MAIL and FTP flows will be selected by address; for them we have:

WWW and DNS flows will be selected by protocol/port (this will include incoming Internet flows); rest of the flows will be selected by default then we have:

6. Assign the CQ to the interface 
The final command will be:

We have finished!! As you see the configuration is a little bit complicated. But going slowly, carefully and having good will it is possible. Let's follow with WFQ queuing discipline.
  Warning: again be careful when experimenting with QoS. Some delay and jitter side effects can be present with CQ when combining a 'jerky' configuration with packet fragmentation. Test well your ideas before trying to have them on production. Also be careful that DNS requires also TCP on port #53 to work. I give this problem to you to be resolved.
 

 
Previous

Content

Next