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).

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

QoS template – bandwidth dependency calculation:

Cisco QoS features like LLQ and CBWFQ let us to prioritize and guarantee delay and bandwidth for defined class of traffic.
CBWFQ configuration allows to configure the BW requirements for specific class of service. First we have to defined the class and match the specific type of traffic, then assign BW limit in the policy that will be reserverd during interface congestion. Standard bandwidth command with BW in Kbps under class can be used for above. The drawback of this type of configuration is need to adjust the BW speed definition each time once we have changed the access speed.

IOS allows to tune the QoS configuration to define kind of QoS template that will use BW class ratio accross function similar devices without need for reconfiguration of BW parameters each time when access speed change. LLQ defines the priority queue for the delay sensetive traffic. Additionaly for business critical traffic CBWFQ needs to be configured. We have two options to confgure the QoS template: bandwidth percent and bandwidth remaining percent per class options.

I have defined 4 classes that will be used to presents configuration options.
class-map match-all TELNET
match protocol telnet
class-map match-all HTTP
match protocol http
class-map match-all SMTP
match protocol smtp
class-map match-all VoIP
match protocol rtp

Option 1 – bandwidth percent
First option to define BW template is to use bandwidth percent command instead of just bandwidth under class in policy map configuration. BW will be calculated based on the interface’s BW, so in case Fast Ethernet it will be 100Mbps. Priority percent 10 for PQ or bandwidth percent 10 in CBWFQ it’s 10% of 100Mbps.

By default, available interface BW is defined based on the physical port speed unless you configure the bandwidth command under interface to set access speed to something less (SLA access). Additionaly Cisco IOS has Default Class (class-default) with reserved the 25% of interface BW that match all undefined traffic (you can change it with max-reserved-bandwidth command under interface mode).

Let’s configure the first policy based on option 1:
R1(config)#policy-map LLQ
R1(config-pmap)#class VoIP
R1(config-pmap-c)#priority percent 10
R1(config-pmap-c)#class HTTP
R1(config-pmap-c)#bandwidth percent 10
R1(config-pmap-c)#class SMTP
R1(config-pmap-c)#bandwidth percent 50
R1(config-pmap-c)#class TELNET
R1(config-pmap-c)#bandwidth percent 30


The first way choice is to configure the bandwidth percent to fil 100% of interface speed, but due to class-default the available BW to share is 75%. In the above example we have defined 4 classed and assigned 100% of interface BW, here let’s try to assign the LLQ policy to the inerface:
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int fa0/0
R1(config-if)#service-policy output LLQ
I/f FastEthernet0/0 class TELNET requested bandwidth 30%, available only 5%
R1(config-if)#

We can observe the error message that is saying that we have just 5% of available BW, this is due to 25% reserved for default class. OK so let change reserved BW for TELNET to 5%, assign policy to the interface and see the policy.
R1#show policy-map interface fastEthernet 0/0
FastEthernet0/0
Service-policy output: LLQ
Class-map: VoIP (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol rtp
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 10 (%)
Bandwidth 10000 (kbps) Burst 250000 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0
Class-map: HTTP (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol http
Queueing
Output Queue: Conversation 265
Bandwidth 10 (%)
Bandwidth 10000 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: SMTP (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol smtp
Queueing
Output Queue: Conversation 266
Bandwidth 50 (%)
Bandwidth 50000 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: TELNET (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol telnet
Queueing
Output Queue: Conversation 267
Bandwidth 5 (%)
Bandwidth 5000 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any

Policy has been defined for Fast Ethernet so LLQ and CBWFQ have 75Mbps traffic reserved, below BW calculation details:

VoIP = 100Mbps * 0,1 = 10Mbps
HTTP = 100Mbps * 0,1 = 10Mbps
SMTP = 100Mbps * 0,5 = 50Mbps
TELNET = 100Mbps * 0,05 = 5Mbps

Option 2 – bandwidth remaining percent
Second option to define BW is to use bandwidth remaining percent command. The idea of this type of configuration is to first reserve the BW for the PQ thru priority percent command and next divides the available remaining BW between defined classes.
Let’s configure below:
R1(config)#policy-map LLQ
R1(config-pmap)#class VoIP
R1(config-pmap-c)#priority percent 10
R1(config-pmap-c)#class HTTP
R1(config-pmap-c)#bandwidth remaining percent 10
R1(config-pmap-c)#class SMTP
R1(config-pmap-c)#bandwidth remaining percent 50
R1(config-pmap-c)#class TELNET
R1(config-pmap-c)#bandwidth remaining percent 40
R1(config-pmap-c)#int fa0/0
R1(config-if)#service-policy output LLQ


For class VoIP priority percent 10 will be equal 100Mbps*0,1=10Mbps, BW Remaining is = (100-10)Mbps * 0,75= 67,5Mbps. So BW Remaining will be used as reference for all classes.
For class HTTP bandwidth remaining percent 10 will be equal BW Remaining*0,1 = 67,5Mbps*0,1= 6,75 Mbps.
For class SMTP bandwidth remaining percent 50 will be equal BW Remaining*0,5 = 33,75 Mbps.
For class TELNET bandwidth remaining percent 40 will be equal BW Remaining*0,4 = 27 Mbps.
By default Burst for Strict Priority queue is equal 20% of the PQ’s BW so 20% of 10Mbps, (10000000bitów/8)*0,2=250000B

R1#show policy-map interface fa0/0
FastEthernet0/0
Service-policy output: LLQ
Class-map: VoIP (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol rtp
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 10 (%)
Bandwidth 10000 (kbps) Burst 250000 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0
Class-map: HTTP (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol http
Queueing
Output Queue: Conversation 265
Bandwidth remaining 10 (%)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: SMTP (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol smtp
Queueing
Output Queue: Conversation 266
Bandwidth remaining 50 (%)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: TELNET (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol telnet
Queueing
Output Queue: Conversation 267
Bandwidth remaining 40 (%)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
30 packets, 2851 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any

Above examples are Cisco recommended ways to deploye CE QoS configuration for different access speed port.