Home » QoS » Congestion Management and Queuing Methods

Congestion Management and Queuing Methods

The various queuing methods available on Cisco routers are

1. FIFO – Legacy queuing method
2. Priority Queuing – Legacy queuing method
3. Customer Queuing – Legacy queuing method
4. Weighted Fair Queuing – Legacy queuing method
5. Class Based Weighted Fair Queuing – Newer queuing method
6. LLQ – Newer queuing method

All these congestion management tools are only activated if the interface or the link is experiencing congestion, if there is no congestion then the packets are sent out of the interface as soon as they arrive. Essentially there are two processes involved in handling the packets when there is congestion – Queuing and Scheduling. Both of these processes are complimentary to each other. Scheduling is a process which handles the packets exiting out of the device, and queuing is the process which handles the incoming packets into the device. Assuming that there is congestion on the output interface then on the input interface the packets are queued into various queues and then given to the output interface where the scheduler processes the queues in order of priority.

FIFO:
First In First Out (FIFO) is a Fair Queuing method, the first packet to get to the router will be the first packet to be sent out.There is only one queue with FIFO, One Queue for received traffic and one queue for traffic being sent out of the router. This is essentially the best effort queuing strategy which gives no priority to any traffic types and  is not recommended for voice and video applications deployments.

Priority Queuing:
There are 4 Queues of Traffic in Priority queuing, and you define what type of traffic goes into these queues. The 4 types of Queues are based on Priorities which are High, Medium, Normal and Low Priority Queue.
This is how Priority Queuing works, as long as there is traffic in High Queue, the other Queues will be neglected, the next to be processed will be traffic in Medium Queue and as long as there is traffic in Medium Queue, the traffic in normal and low queues will be neglected.  Also, while serving the traffic in Medium Queue, if the router receives traffic in High Queue, then High Queue will be processed and unless all traffic has cleared the High Queue the router will not go back to Medium Queue. This could result in resource starvation for the traffic arriving and sitting on the lower priority queues like the normal and low queues.
Priority Queuing is a strict Priority method, which will always prefer the traffic in High Priority Queue to other queues, and the order of processing is
High Priority Queue > Medium Priority Queue > Normal Priority Queue>Low Queue
So, Priority Queuing can give delay guarantee to traffic in high Queues, but can also lead to resource starvation to traffic in other queues.

Custom Queuing:
There are 16 Queues defined in Custom Queuing. Custom Queuing works in a round robin method, there are 16 queues where you define which traffic will go in which queue. It starts from clearing the traffic in the first queue then it will jump to next queue and clear all traffic in the second queue then jump to next queue and clear the traffic and so on,, and then when all queues all  sent, it will go back to the first queue and start the process all over again. This queuing will make sure that no traffic queue will ever have a resource starvation but at the same time it cannot give delay guarantee so its not recommended for voice and video traffic. When implementing custom queuing you can define which traffic and how much metrics to each queue which will be processed before jumping to next queue, for an example you can say Queue 1  Http traffic  10000 Kb, then Q2 FTP traffic 8000 Kb .. and the custom queuing will follow this order in a round robin fashion.

 

 

Weighted Fair Queuing:
The number of Queues are defined per flow. This is also the default queuing method Cisco has for most serial links.  The low talkers get priority over the high talkers in WFQ  method – what this means is that the flow which has least traffic will get preference over  flow which has more traffic (voice and video might not be filling up the bandwidth but they will have steady flow of traffic, so the traffic in this flow will be considered as top talker  again may not necessarily be taking up all bandwidth) There is no bandwidth guarantee and no delay guarantee over the WFQ. It is not recommended for the voice and video traffic because even though the voice or video packets are small they are always sending some packets (always talking) and so they are considered high talkers per flow, so if someone does a telnet or ssh in between then those packets will get priority as they are considered low talkers per number of flows.

Class Based Weighted Fair Queuing (CBWFQ):
CBWFQ defines up to 256 classes of traffic. This is the new Queuing method which can be deployed using the Cisco MQC. Again there is no delay guarantee on this method as well, but there is bandwidth guarantee. In this method you can use class-maps to define upto 256 classes of traffic and assign how much percentage of bandwidth each class is guaranteed to get.  You can define all the traffic classes and assign the bandwidth percentage guarantee to each class, and then there is a class-default which is the default class, all traffic which did not match into your custom defined classes falls in this  class-default  bucket, within this default class the traffic is treated with WFQ. CBWFQ  is a huge improvement over all other earlier congestion management techniques but is still not recommended for voice and video as there is no delay guarantee.

Low Latency Queuing (LLQ):
The only queuing method which can be used for voice and video traffic.
This queuing method is a combination of Priority Queuing and CBWFQ.
What this does is as an example, Voice will be in the Priority Queue with a bandwidth limit which is policed (Ex 800 K) and the rest of the traffic will be CBWFQ where each application will get its percentage of bandwidth guarantee (Ex Email 20%, HTTP 20% etc).
So essentially there is a Priority Queue which can be used for Voice which gives us delay guarantee and the bandwidth guarantee as we can specify how much bandwidth to give to this Priority Queue which ensures that this Priority Queue is not taking up all the bandwidth.  Also for other applications we have the CBWFQ where we can define the mission critical applications and allocate the remaining bandwidth percentage to them, and at the end what ever traffic which does not match the user defined classes in the CBWFQ will automatically match the class default and will be treated with WFQ method.

Note: That LLQ defines using only 1 Priority Queue for a traffic Type, if you define more than One Priority Queue using the LLQ, then the High Priority Queue will be processed first and until the High Priority Queue is not empty the other Queue will not be processed, but the CBWFQ classes will be processed in parallel.

LLQ Guidelines
Priority Queue = 33% (Voice and Video)
Sum of all Guarantees = 75% (this includes the 33% for the Priority Queue)
This is to make sure that 25% is left for the Default Class (everything else).

End-to-End QoS Network Design: Quality of Service for Rich-Media & Cloud Networks (2nd Edition) (Networking Technology)


Incoming search terms for the article:

Leave a Reply