Low-Latency Queuing (LLQ)

LLQ

Low-Latency Queuing (LLQ) is essentially CBWFQ combined with a strict priority queue. Traffic assigned to the strict priority queue, using the priority command, is completely serviced before all other CBWFQ queues are serviced. LLQ bandwidth, like CBWFQ bandwidth, can be assigned either in absolute kbps or as a percentage of the link’s bandwidth (using the priority percent command).

Note

The original name for the LLQ algorithm was Priority-Queue-Class-Based Weighted-Fair Queuing (PQ-CBWFQ). Although this name was technically more descriptive, it was obviously clumsy from a marketing perspective, hence, the algorithm was renamed LLQ.

To better understand how LLQ works, Example 1 adds a strict priority queue, to support VoIP

Example 1: LLQ/CBWFQ Policy Example

---

Router(config)# policy-map LLQ
Router(config-pmap)# class VOICE
Router(config-pmap-c)# priority 100
Router(config-pmap-c)# class CALL-SIGNALING
Router(config-pmap-c)# bandwidth percent 5
Router(config-pmap-c)# class TRANSACTIONAL-DATA
Router(config-pmap-c)# bandwidth percent 20
Router(config-pmap-c)# class BULK-DATA
Router(config-pmap-c)# bandwidth percent 10
Router(config-pmap-c)# class class-default
Router(config-pmap-c)# fair-queue

---

Next, look at Figure 1 to see what has changed in the underlying queuing mechanisms when LLQ has been combined with CBWFQ.

 
Figure 1: LQ and CBWF Q mechanisms

Note

For the sake of simplicity, some Layer 2 subsystems (including Link Fragmentation and Interleaving) have been omitted from Figure 1 because these mechanisms simply aren’t relevant at the link speeds required by TelePresence.

In Figure 1, you see a router interface that has been configured with a 5-class LLQ/CBWFQ policy, with voice assigned to a 100-kbps LLQ, and additional three explicit CBWFQs defined for Call-Signaling, Transactional Data, and Bulk Data respectively, and a default queue that has a Fair-Queuing pre-sorter assigned to it. However, an underlying mechanism that might not be obvious from the configuration, but is shown in the illustration, is an implicit policer attached to the LLQ.

The threat posed by any strict priority-scheduling algorithm is that it can completely starve lower-priority traffic. To prevent this, the LLQ mechanism has a built-in policer. This policer (like the queuing algorithm itself) engages only when the LLQ-enabled interface is experiencing congestion. Therefore, it is important to provision the priority classes properly. In this example, if more than 100 kbps of voice traffic was offered to the interface, and the interface was congested, the excess voice traffic would be discarded by theimplicit policer. However, traffic that is admitted by the policer gains access to the strict priority queue and is handed off to the Tx-Ring ahead of all other CBWFQ traffic.

Now, consider the case of servicing not just voice with strict-priority LLQ, but also real-time interactive-video (which, for these two following examples, is abbreviated simply asvideo).

Two options exist to the network administrator. The first is to admit both voice and video to the same LLQ. Thus the second LLQ example policy becomes what is shown in Example 2.

Example 2: Aggregate LLQ for Voice and Video Policy Example

---

Router(config)# class-map match-any REALTIME
Router(config-cmap)# match dscp ef
Router(config-cmap)# ! Matches VoIP on DSCP EF (per RFC4594)
Router(config-cmap)# match dscp cs4
Router(config-cmap)# ! Matches Realtime-Interactive Video on CS4 (per RFC4594)
Router(config-cmap)#
Router(config-cmap)# policy-map LLQ2
Router(config-pmap)# class REALTIME
Router(config-pmap-c)# priority 500
Router(config-pmap-c)# ! Combined LLQ for VoIP and Video
Router(config-pmap-c)# class CALL-SIGNALING
Router(config-pmap-c)# bandwidth percent 5
Router(config-pmap-c)# class TRANSACTIONAL-DATA
Router(config-pmap-c)# bandwidth percent 20
Router(config-pmap-c)# class BULK-DATA
Router(config-pmap-c)# bandwidth percent 10
Router(config-pmap-c)# class class-default
Router(config-pmap-c)# fair-queue

---

Figure 2 illustrates the corresponding IOS mechanisms for this second LLQ example.

 
Figure 2: Aggregate LLQ for voice and video policy mechanisms

In Figure 2, you can see that not only has the LLQ been expanded in size (to 500 kbps), but also the implicit policer (for the combined VoIP and TelePresence class) has been increased to 500 kbps. Such a policy can continue to protect voice from data and video from data. However, this policy does potentially allow video to interfere with voice. This is because traffic offered to the LLQ class is serviced on a first-come, first-serve basis. Therefore, should video traffic suddenly burst, it is possible (even likely) that voice traffic would be dropped.

At this point, you can realize another benefit of the implicit policer for the LLQ—not only does this mechanism protect nonreal-time queues from bandwidth-starvation, but also it allows for Time-Division Multiplexing (TDM) of the LLQ. TDM of the LLQ allows for the configuration and servicing of multiple LLQs, while abstracting the fact that there is only a single LLQ “under-the-hood,” so to speak. Pertinent to the example, by configuring two LLQs, not only are voice and video protected from data applications, but also voice and video are protected from interfering with each other.

Example 3 provides the final policy example to cover this point, wherein a dual-LLQ design is used, one each for voice and video.

Example 3: Dual-LLQ for Voice and Video Policy Example

---

Router(config)# class-map match-all VOICE
Router(config-cmap)# match dscp ef
Router(config-cmap)# ! Matches VoIP on DSCP EF (per RFC4594)
Router(config-cmap)# class-map match-all VIDEO
Router(config-cmap)# match dscp cs4
Router(config-cmap)# ! Matches Realtime-Interactive Video on CS4 (per RFC4594)
Router(config-cmap)# !
Router(config-cmap)# policy-map LLQ3
Router(config-pmap)# class VOICE
Router(config-pmap-c)# priority 100
Router(config-pmap-c)# ! Provisions 100 kbps of LLQ for VoIP
Router(config-pmap-c)# class VIDEO
Router(config-pmap-c)# priority 400
Router(config-pmap-c)# ! Provisions 400 kbps of LLQ for Realtime-Interactive Video
Router(config-pmap-c)# class CALL-SIGNALING
Router(config-pmap-c)# bandwidth percent 5
Router(config-pmap-c)# class TRANSACTIONAL-DATA
Router(config-pmap-c)# bandwidth percent 20
Router(config-pmap-c)# class BULK-DATA
Router(config-pmap-c)# bandwidth percent 10
Router(config-pmap-c)# class class-default
Router(config-pmap-c)# fair-queue

---

Figure 3 illustrates the corresponding IOS mechanisms for this third LLQ example.

 
Figure 3: Dual-LLQ for vice and video policy mechanisms

In Figure 3, you see that two separate implicit policers have been provisioned, one each for the VoIP class (to 100 kbps) and another for the Video class (to 400 kbps), yetthere remains only a single strict-priority queue, which is provisioned to the sum of all LLQ classes, in this case to 500 kbps (100 kbps + 400 kbps). Traffic offered to either LLQ class is serviced on a first-come, first-serve basis until the implicit policer for each specific class has been invoked. For example, if the video class attempts to burst beyond its 400 kbps rate, it will be dropped.

Therefore, when considering designs to support real-time applications, such as VoIP and TelePresence (an Interactive-Video application, as defined in RFC 4594), a dual-LLQ design can provide the best levels of service for VoIP and TelePresence, while preventing these from interfering with each other.

Class-Based Weighted-Fair Queuing (CBWFQ)

CBWFQ

Class-Based Weighted-Fair Queuing (CBWFQ) is a queuing algorithm that combines the capability to guarantee bandwidth with the capability to dynamically ensure fairness to other flows within a class of traffic.

CBWFQ allows for the creation of up to 64 classes of traffic, each with its own reserved queue. Each queue is serviced in a weighted-round-robin (WRR) fashion based on the bandwidth assigned to each class. Bandwidth might be assigned to a class in terms of absolute kbps (with the bandwidth command), as a percentage of a link’s bandwidth (with the bandwidth percent command), or as a percentage of bandwidth remaining, after the strict-priority Low-Latency Queue has been serviced (with the bandwidth remaining command).

To better understand how CBWFQ works, Example 1 begins by constructing a simple CBWFQ policy.

Example 1: CBWFQ Policy Example

---

Router(config)# policy-map CBWFQ
Router(config-pmap)# class NETWORK-CONTROL
Router(config-pmap-c)# bandwidth percent 5
Router(config-pmap-c)# class TRANSACTIONAL-DATA
Router(config-pmap-c)# bandwidth percent 20
Router(config-pmap-c)# class BULK-DATA
Router(config-pmap-c)# bandwidth percent 10
Router(config-pmap-c)# class class-default
Router(config-pmap-c)# fair-queue

---

Next, look at the underlying CBWFQ mechanisms that correspond with this policy, as illustrated in Figure 1.

 
Figure 1: Class-Based Weighted-Fair Queuing mechanisms

In Figure 1, you see a router interface that has been configured with a 4-class CBWFQ policy, with an explicit CBWFQ defined for Network Control, Transactional Data, and Bulk Data, respectively, and the default CBWFQ queue, which has a Fair-Queuing (FQ) pre-sorter assigned to it.

Note

CBWFQ is a bit of a misnomer because the pre-sorter that can be applied to certain CBWFQs, such as class-default, is not actually a Weighted-Fair Queuing (WFQ) pre-sorter, but rather a Fair-Queuing (FQ) pre-sorter, and as such, it ignores any IP Precedence values when calculating bandwidth allocation traffic flows. To be more technically accurate, this queuing algorithm would be better named Class-Based Fair-Queuing or CBFQ.

Another underlying queuing mechanism is a final (FIFO) output buffer called the Tx-Ring, which serves the purpose of always having packets ready to be placed onto the wire so that link utilization can be driven to 100 percent. The Tx-Ring also serves to indicate congestion to IOS. Specifically, when the Tx-Ring fills to capacity, the interface is known to be congested, and a signal is sent to engage any LLQ/CBWFQ policies that have been configured on the interface.

CBWFQ works in the following manner:

1. Packets are classified according to the class maps and assigned to either explicitly defined CBWFQs or to the default queue. If the packets are assigned to the default queue and fair-queuing has been enabled on the default class with the fair-queue subcommand, packets receive a proportionately equal share of the available bandwidth for the default queue. For example, if there is 100 kbps assigned to the default queue and there are 10 IP flows that are contenting for the default queue, each flow is assigned an equal share (10 kbps) of bandwidth by the FQ pre-sorter.
2. Next, the CBWFQ scheduler dequeues the packets from each CBWFQ in a weighted-round-robin (WRR) manner that reflects the proportionate bandwidth allocations per-class.
3. These packets are then enqueued into the Tx-Ring.
4. Finally, the packets exit the Tx-Ring in a FIFO manner as they are transmitted across the physical interface media.

CBWFQ is a highly efficient queuing algorithm for data applications but lacks the capability to provide strict-priority servicing to real-time applications, such as voice or interactive video. This is because it provides a bandwidth guarantee but not a latency/jitter guarantee. Therefore, to service such real-time applications, a strict-priority queue was added to the CBWFQ algorithm, and the resulting algorithm was named Low-Latency Queuing.

Shaping Tools | Network Quality of Service

Shapers operate in a manner similar to policers in that they invoke token bucket algorithms to meter traffic. However, the principle difference between a policer and a shaper is that where a policer re-marks or drops traffic as a policy action, a shaper merely delays traffic. Even though TelePresence is a real-time application, you might encounter scenarios, such as subline rate access scenarios, which require shaping policies to be included within a comprehensive TelePresence QoS policy. Figure 1 illustrates generic traffic shaping.

 
Figure 1: Generic traffic shaping effect on traffic flow

Shapers are particularly useful when traffic must conform to a specific rate of traffic to meet a service-level agreement (SLA) or to guarantee that traffic offered to a service provider is within a contracted rate. Additionally, shapers have long been associated with Non-Broadcast Multiple-Access (NBMA) WAN topologies, such as ATM and Frame Relay, where potential speed-mismatches exist. However, shapers are becoming increasingly popular on newer Layer 3 WAN access circuits, such as Ethernet-based handoffs, to conform to subline access rates.

Shapers, like policers, use token bucket algorithms. On most platforms, by default, IOS shapers set the Bc to equal CIR/8, which yields an interval (Tc) of 125 ms. Although this interval value might be adequate for data applications, it introduces unnecessary interpacket delays for real-time networks. Consider the example shown in Figure 2.

 
Figure 2: Shaping behavior with default Bc values

A shaper uses the CIR, Bc, and Be to smooth a traffic stream to a specified rate. It achieves the given CIR by taking the line speed of the interface and dividing it into equal length timeslots (Intervals, or Tc) and then sends a smaller portion (Bc) of the traffic during each timeslot. The timeslot size is governed by the Bc parameter (Tc = Bc / CIR). In Figure 2, a line rate of 128 kbps is shaped to 64 kbps. The Bc, by default, is one eighth of the CIR (or eight kbps). Each second is divided into eight timeslots of 125 ms each, and the shaped rate of 64,000 bps is divided into eight bursts of 8000 bps each (Bc). Each burst will take 62.5 ms to transmit (at a 128 kbps line rate). So the shaper transmits information for the first 62.5ms of each 125 ms timeslot and is silent for the remaining 62.5 ms of the timeslot. Over the span of a second, this achieves the average rate of CIR.

Additionally, you can use the Be value to determine the peak Rate of sending, which is calculated as follows:

Peak Rate = CIR (1 + Be / Bc)

Peak-rate shaping allows the router to burst higher than average-rate shaping. However, when peak-rate shaping is enabled, any traffic exceeding the CIR can be dropped if the network becomes congested.

A router interface might be configured to shape using average rates, through the shape average policy-action command, or to a peak rate, through the shape peak policy-action command. The configuration for a basic Class-Based Shaping policy to shape to an average rate of 5 Mbps is as follows:

Router(config)# policy-map CB-SHAPING-5MBPS
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape average 5000000

Because shaping involves buffering, various queuing techniques might be activated when the shaping buffer has been filled to capacity.