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.
| 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.
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.
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.
No comments:
Post a Comment