Low-Latency Queuing (Congestion Management and Queuing)

Neither WFQ nor CBWFQ can provide guaranteed bandwidth and low-delay guarantee to selected applications such as VoIP; that is because those queuing models have no priority queue. Certain applications such as VoIP have a small end-to-end delay budget and little tolerance to jitter (delay variation among packets of a flow).

LLQ includes a strict-priority queue that is given priority over other queues, which makes it ideal for delay and jitter-sensitive applications. Unlike the plain old PQ, whereby the higher-priority queues might not give a chance to the lower-priority queues and effectively starve them, the LLQ strict-priority queue is policed. This means that the LLQ strict-priority queue is a priority queue with a minimum bandwidth guarantee, but at the time of congestion, it cannot transmit more data than its bandwidth permits. If more traffic arrives than the strict-priority queue can transmit (due to its strict bandwidth limit), it is dropped. Hence, at times of congestion, other queues do not starve, and get their share of the interface bandwidth to transmit their traffic.

Figure 4-6 shows an LLQ. As you can observe, LLQ is effectively a CBWFQ with one or more strict-priority queues added. Please note that it is possible to have more than one strict priority queue. This is usually done so that the traffic assigned to the two queues—voice and video traffic, for example—can be separately policed. However, after policing is applied, the traffic from the two classes is not separated; it is sent to the hardware queue based on its arrival order (FIFO).

Figure 4-6 LLQ

As long as the traffic that is assigned to the strict-priority class does not exceed its bandwidth limit and is not policed and dropped, it gets through the LLQ with minimal delay. This is the benefit of LLQ over CBWFQ.

Benefits of LLQ

LLQ offers all the benefits of CBWFQ, including the ability of the user to define classes and guarantee each class an appropriate amount of bandwidth and to apply WRED to each of the classes (except to the strict-priority queue) if needed. In the case of LLQ and CBWFQ, the traffic that is not explicitly classified is considered to belong to the class-default class. You can make the queue that services the class-default class a WFQ instead of FIFO, and if needed, you can apply WRED to it.

The benefit of LLQ over CBWFQ is the existence of one or more strict-priority queues with bandwidth guarantees for delay- and jitter-sensitive traffic. The advantage of LLQ over the traditional PQ is that the LLQ strict-priority queue is policed. That eliminates the chance of starvation of other queues, which can happen if PQ is used. As opposed to the old RTP priority queue, the LLQ strict-priority is not limited to accepting RTP traffic only. You can decide and assign any traffic you want to the LLQ strict-riority queue using special IOS keywords, using access lists, or using Network Based Application Recognition (NBAR) options. Finally, like many other queuing mechanisms, LLQ is not restricted to certain platforms or media types.

Configuring and Monitoring LLQ

Configuring LLQ is almost identical to configuring CBWFQ, except that for the strict-priority queue(s), instead of using the keyword/command bandwidth, you use the keyword/command priority within the desired class of the policy map. You can reserve bandwidth for the strict-priority queue in two ways: you can specify a fixed amount, or you can specify a percentage of the interface bandwidth. The following command syntax is used to do just that in the appropriate order:

The burst amount (bytes) is specified as an integer between 32 and 2,000,000; it allows a temporary burst above the policed bandwidth. Note that if the percent option is used, the reservable amount of bandwidth is limited by the value of max-reserved-bandwidth on the interface configuration, which is 75 percent by default.

Example 4-7 shows implementation of LLQ using a policy map called enterprise. The policy map assigns a class called voice to the strict-priority queue with a bandwidth guarantee of 50 Kbps. Classes business and class-default form the CBWFQ component of this LLQ.

Example 4-7 A Policy Map to Implement LLQ

You can use the show policy-map interface interface command to see the packet statistics for all classes used within a policy map that is applied to an interface using the service-policy command. Example 4-8 shows (partial) output of this command for the serial 1/0 interface of a router.

Example 4-8 Sample Output of the show policy-map interface Command

Foundation Summary

The "Foundation Summary" is a collection of information that provides a convenient review of many key concepts in this topic. If you are already comfortable with the topics in this topic, this summary can help you recall a few details. If you just read this topic, this review should help solidify some key facts. If you are doing your final preparation before the exam, the information in this section is a convenient way to review the day before the exam.

Congestion happens when the rate of input (incoming traffic switched) to an interface exceeds the rate of output (outgoing traffic) from an interface. Aggregation, speed mismatch, and confluence are three common causes of congestion. Queuing is a congestion management technique that entails creating a few queues, assigning packets to those queues, and scheduling departure of packets from those queues. Table 4-2 provides a comparative summary for the queuing disciplines discussed in this topic.

Table 4-2 Comparison of FIFO, PQ, WRR (CQ), WFQ, CBWFQ, and LLQ