288 Chapter 4: Congestion Management

Table 4-13 CBWFQ Comparison to Other WFQ Tools

Low Latency Queuing (LLQ)

Low Latency Queuing sounds like the best queuing tool possible, just based on the name. What packet wouldn’t want to experience low latency? As it turns out, for delay (latency) sensitive traffic, LLQ is indeed the queuing tool of choice.

LLQ is simple to understand and simple to configure, assuming you already understand CBWFQ. LLQ is not really a separate queuing tool, but rather a simple option of CBWFQ applied to one or more classes. CBWFQ treats these classes as strict-priority queues. In other words, CBWFQ always services packets in these classes if a packet is waiting, just as PQ does for the High queue.

NOTE This section uses examples with only a single LLQ class in most cases. However, you can have more than one low-latency priority queue at the same time. It is very important that you read the section titled “LLQ with More Than One Priority Queue,” just before the section about configuring LLQ. This section not only explains why you might want more than one lowlatency queue, but it also covers some important information for the exam.

LLQ introduces some new lingo that you may find a little tricky. From one perspective, something like PQ has been added to CBWFQ, so you can expect to read or hear phrases that refer to the low-latency queue as “the PQ.” Someone might say, “What did you put in the PQ?” What he really wants to know is what type of packets you classified and placed into the queue in which you enabled the LLQ feature of CBWFQ. In addition, the queue in which LLQ is enabled is sometimes just called “the LLQ.” Therefore, if you use CBWFQ, and use the priority command to enable LLQ in one of the classes, you are really using LLQ, and that one class with the priority command is “the LLQ” or “the PQ.”

Terminology aside, the simple addition of LLQ logic to CBWFQ is depicted in Figure 4-21.

Queuing Tools 289

Figure 4-21 Servicing Queues with LLQ and CBWFQ

Note that like PQ, the LLQ scheduler always checks the low-latency queue first, and takes a packet from that queue. If there are no packets in the low-latency queue, the normal, unpublished scheduler logic applies to the other non-low-latency queue queues, giving them their guaranteed bandwidth. For delay-sensitive traffic, the addition of a low-latency queue overcomes the one big negative of CBWFQ. In fact, with all the other queuing tools covered in this chapter so far, only PQ gave voice traffic the best quality. Of course, PQ had the negative side effect of almost destroying the performance of the lower-priority applications when the link was congested. With LLQ, you get the best of both worlds—low latency for the traffic in one queue, and guaranteed bandwidth for the traffic in other queues. Notice the thicker lines in Figure 4- 21. If you follow these lines, you can see a path through the logic for LLQ in which only the low-latency queue gets any service. How can LLQ guarantee the other queues their respective bandwidths, with logic that never lets those queues get serviced? Well, the real answer is that Figure 4-21 is only part of the story. To prevent LLQ from having the same problem as PQ, where packets in the highest-priority queue could dominate and take all the available bandwidth, LLQ’s scheduler actually operates as shown in Figure 4-22.

Figure 4-22 Services Queues with LLQ and CBWFQ—The Real Story

290 Chapter 4: Congestion Management

LLQ actually polices the PQ based on the configured bandwidth. By doing so, the packets in the queue that are forwarded still have very low latency, but LLQ also prevents the low-latency traffic from consuming more than its configured amount of bandwidth. By discarding excess traffic, LLQ can still provide bandwidth guarantees to the non-priority queues. The policing function works like policing as described in Chapter 5, but it is automatic in the low-latency queue—no additional policing configuration is required.

The policing function of LLQ takes care of protecting the other queues from the low-latency queue, but it does discard packets to accomplish that goal. Take a moment to reflect on the types of traffic that need to be classified into the low-latency queue. VoIP traffic, and in most cases, video traffic, need the low-latency, low-jitter performance of the low-latency queue. However, these are the same types of traffic that are most sensitive to dropped packets. So, although putting voice and interactive video into the low-latency queue may be good for queuing, discarding packets that exceed the configured rate for the queue would be harmful to those types of traffic. (Remember, interactive video needs low latency, but one-way video does not.)

The solution to the LLQ policing feature’s bad effect on VoIP and interactive video traffic lies outside the control of LLQ. The solution requires the engineer to use whatever means necessary to prevent more than the reserved bandwidth for a low-latency queue from getting introduced into the network. If the low-latency queue has 30 kbps reserved, for example, a single G.729 call will never cause the policer to discard a packet. If a second call occurs, the policer will discard packets, and both voice calls will sound bad. The solution requires some engineering, and some use of call admission control (CAC) tools, to prevent the low-latency queue from being oversubscribed.

LLQ Configuration

LLQ configuration requires one more command in addition to the commands used for CBWFQ configuration. Instead of using the bandwidth command on a class, use the priority command. This single additional command is listed in Table 4-24. The syntax for this command is as follows:

priority {bandwidth-kbps | percent percentage} [burst]

This class subcommand enables LLQ in this class, reserves bandwidth, and enables the policing function. You can also configure the burst for the policer with this command, and it defaults to 20 percent of the configured policing rate.

The priority command sets the guaranteed minimum bandwidth, which is also the maximum bandwidth! As mentioned earlier, LLQ polices the traffic in a class that uses the priority command and discards excess traffic. The burst parameter works just like bursts do for policing tools described in Chapter 5; refer to Chapter 5 for more details on the concepts behind policing.

In the following example, the final lab scenario used in the CBWFQ section is repeated, except that LLQ is also enabled. The class with VoIP traffic has reserved 58 kbps again, but this time using the priority command. With two VoIP calls, the voice sounds fine. The same familiar

292 Chapter 4: Congestion Management

Example 4-8 LLQ for VoIP, CBWFQ for NetMeeting, HTTP “important,” HTTP “not-so” Important, and

Everything Else (Continued)

policy-map laundry-list class voip-rtp

set ip dscp ef class NetMeet

set ip dscp af41 class http-impo

set ip dscp af21 class http-not

set ip dscp af23 class class-default set ip dscp default policy-map queue-on-dscp

class dscp-ef priority 58

class dscp-af41 bandwidth 22 class dscp-af21 bandwidth 20

random-detect dscp-based class dscp-af23

bandwidth 8 random-detect dscp-based

class class-default fair-queue

random-detect dscp-based

!

interface Ethernet0/0

description connected to SW2, where Server1 is connected ip address 192.168.3.253 255.255.255.0

ip nbar protocol-discovery half-duplex

service-policy input laundry-list

!

interface Serial0/0

description connected to FRS port S0. Single PVC to R1. bandwidth 128

no ip address encapsulation frame-relay load-interval 30 max-reserved-bandwidth 85

service-policy output queue-on-dscp clockrate 128000

!

interface Serial0/0.1 point-to-point

description point-point subint global DLCI 103, connected via PVC to DLCI 101 ( R1)

ip address 192.168.2.253 255.255.255.0 frame-relay interface-dlci 101

!

access-list 101 permit udp host 192.168.3.100 range 16384 32767 192.168.1.0 0.0.0.255 range 16384 32767

294 Chapter 4: Congestion Management

Example 4-8 LLQ for VoIP, CBWFQ for NetMeeting, HTTP “important,” HTTP “not-so” Important, and

Everything Else (Continued)

Service-policy output: queue-on-dscp

Class-map: dscp-ef (match-all) 227428 packets, 14555392 bytes

30 second offered rate 52000 bps, drop rate 0 bps Match: ip dscp ef

Weighted Fair Queueing Strict Priority

Output Queue: Conversation 40 Bandwidth 58 (kbps) Burst 1450 (Bytes)

(pkts matched/bytes matched) 12194/780416 (total drops/bytes drops) 0/0

R3#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

R3(config)#policy-map queue-on-dscp

R3(config-pmap)#class dscp-ef

R3(config-pmap-c)#priority 48

R3(config-pmap-c)#^Z

R3#show policy-map interface s 0/0 output class dscp-ef

Serial0/0

Service-policy output: queue-on-dscp

Class-map: dscp-ef (match-all) 279830 packets, 17909120 bytes

30 second offered rate 51000 bps, drop rate 2000 bps Match: ip dscp ef

Weighted Fair Queueing Strict Priority

Output Queue: Conversation 40 Bandwidth 48 (kbps) Burst 1200 (Bytes)

(pkts matched/bytes matched) 64402/4121728 (total drops/bytes drops) 97/6208

R3#

The only change to this configuration, when compared with the CBWFQ configuration in Example 4-8 is that in the dscp-ef class, inside policy-map queue-on-dscp, the priority command rather than the bandwidth command was used to reserve bandwidth. As seen in the output from the show policy-map command, IOS now performs strict-priority queuing on the traffic in class dscp-ef. Also note that the show policy-map output shows a burst value was defined (1450 bytes), which is used by the policing function of LLQ. The default burst size is equal to 200 milliseconds of traffic; 58000 bits/second * .2 seconds equals 11600 bits, or 1450 bytes.

Note also the drops experienced by the voice traffic as shown with the show policy-map interface s 0/0 output class dscp-ef command. The low-latency queue in this example has