Downloads |
Table Of Contents
Distributed Low Latency Queueing
Guaranteeing Bandwidth with the priority Command
Related Features and Technologies
Supported Standards, MIBs, and RFCs
Configuring a Priority Queue for an Amount of Available Bandwidth
Configuring a Priority Queue for a Percentage of Available Bandwidth
Configuring a Transmission Ring Limit
Verifying Low Latency Queueing
Verifying a Transmission Ring Limit
Monitoring and Maintaining Low Latency Queueing
Enabling Priority Queueing for an Amount of Available Bandwidth on an ATM Subinterface
Enabling Priority Queueing for a Percentage of Available Bandwidth on an ATM Subinterface
Limiting the Transmission Ring Limit on an ATM Interface
Limiting the Transmission Ring Limit on an ATM PVC Subinterface
Distributed Low Latency Queueing
Note
This feature was formerly called Low Latency Queueing for the Versatile Interface Processor and might be referred to as Low Latency Queueing for the Versatile Interface Processor (VIP) in some Cisco documentation.
This feature module describes the distributed Low Latency Queueing feature. It includes information on the benefits of the new feature, supported platforms, related documents, and so forth.
This document includes the following sections:
•
•
Feature Overview
The distributed Low Latency Queueing feature brings the ability to specify low latency behavior for a traffic class. Low Latency Queuing allows delay-sensitive data such as voice to be dequeued and sent first (before packets in other queues are dequeued), giving delay-sensitive data preferential treatment over other traffic.
The distributed Low Latency Queueing feature also introduces the ability to limit the depth of a device transmission ring. Before the introduction of distributed Low Latency Queueing, the maximum transmission ring depth was not a user-configurable parameter. Therefore, particles could accumulate on a transmission ring without limitation, which could result in unavoidable high latencies. The distributed Low Latency Queueing feature allows users to limit the number of particles that may exist on a transmission ring, effectively lowering the latency incurred by packets sitting on that transmission ring.
The priority command is used to allow delay-sensitive data to be dequeued and sent first. Low Latency Queueing enables use of a single priority queue within which individual classes of traffic can be placed. To enqueue class traffic to the priority queue, you configure the priority command for the class after you specify the named class within a policy map. The amount of bandwidth available for the priority queue can be specified either as a set amount of bandwidth in kbps or as a percentage of all available bandwidth (beginning in Cisco IOS Release 12.1(5)T).
Within a policy map, you can give one or more classes priority status. When multiple classes within a single policy map are configured as priority classes, all traffic from these classes is enqueued to the same, single, priority queue.
The tx-ring-limit command allows the user to specify the number of allowable particles on a transmission ring, effectively lowering the latency for that transmission ring. One packet can contain multiple particles, and a typical particle is 512 bytes in size (the size depends on the interface types. For some interface types, a typical particle size is 256 bytes). These particles can no longer accumulate on a transmission ring and cause unavoidable high latencies.
Guaranteeing Bandwidth with the priority Command
One method of using the priority command for a traffic class is to specify a bandwidth argument that gives the maximum bandwidth in kilobits per second (kpbs). The other method of using the priority command for a traffic class, which was introduced in Cisco IOS Release 12.1(5)T, is to specify a percentage of available bandwidth to be reserved for the priority queue. The bandwidth value or percentage guarantees the configured bandwidth to the priority class under worst-case congestion scenarios. If excess bandwidth is available, the priority class will be allowed to utilize the bandwidth. If no excess bandwidth is available, the priority traffic will be constrained to the configured rate via packet drops. Each individual class that is configured to a bandwidth value will have its traffic constrained to its individual rate. When a class is constrained to its individual rate, the traffic is permitted a certain amount of burstiness because of the token bucket mechanism policing the stream. This amount of burstiness is controlled by the optional bytes parameter in the priority command (this burstiness cannot be specified when specifying a priority queue based on a percentage of available bandwidth). The bytes parameter specifies, in bytes, the amount of traffic allowed to pass through the token bucket as a one-time burst in excess of the token bucket drop parameters. The default burst value is 200 milliseconds of traffic at the configured token bucket drop parameters.
It is important to note that because bandwidth for the priority class is specified as a parameter to the priority command, you cannot also configure the bandwidth command for a priority class. To do so is a configuration violation that introduces confusion in relation to the amount of bandwidth to allocate.
The bandwidth allocated for a priority queue always includes the Layer 2 encapsulation header. However, it does not include other headers, such as ATM cell tax overheads. When you calculate the amount of bandwidth to allocate for a given priority class, you must account for the fact that the Layer 2 headers are included. When ATM is used, you must account for the fact that ATM cell tax overhead is not included. You must also allow bandwidth for the possibility of jitter introduced by routers in the voice path.
Consider this case that uses ATM: Suppose a voice stream of 60 bytes emitting 50 packets per second is encoded using G.729. Prior to converting the voice stream to cells, the meter for the priority queue used for the voice stream assesses the length of the packet after the Layer logical link control (LLC) headers have been added.
Given the 8-byte Layer 2 LLC header, the meter will take into account a 68-byte packet. Because ATM cells are a standard 53 bytes long, before the 68-kbps packet is emitted on the line, it is divided into two 53-byte ATM cells. Thus, the bandwidth consumed by this flow is 106 bytes per packet.
For this case, then, you must configure the bandwidth to be at least 27.2 kbps (68 * 50 * 8 = 27.2 kbps). However, recall that you must also allow for the ATM cell tax overhead, which is not accounted for by the configured bandwidth. In other words, the sum of the bandwidths for all classes must be less than the interface bandwidth by at least (106 - 68) * 50 * 8 = 15.2 kbps. You should also remember to allow bandwidth for router-introduced jitter.
Benefits
Provides Priority Service on ATM VCs and Serial Interface
The priority queueing scheme allows delay-sensitive data such as voice to be dequeued and sent first—that is, before packets in other queues are dequeued. Delay-sensitive data is given preferential treatment over other traffic. This feature provides priority queueing on ATM virtual circuits (VCs);
Admission Control
By configuring the maximum amount of bandwidth allocated for packets belonging to a class, you can avoid starving non-priority traffic.
Limiting Particles on a Transmission Ring
The distributed Low Latency Queueing feature also introduces particle limiting for transmission rings. Before the introduction of distributed Low Latency Queueing, the transmission ring depth was not user-configurable. Therefore, a user could experience unavoidable high latencies on a transmission ring.
The distributed Low Latency Queueing feature allows users to limit the number of particles on a transmission ring to a predefined limit, effectively lowering the latency on transmission rings.
Restrictions
•
Table 2 Port Adapters that do not Support Distributed LLQ
•
•
•
•
•
The bandwidth and priority commands cannot be used in the same class map. These commands can be used together in the same policy map, however.
The following commands cannot be used in the same class or policy map with the priority command:
–
–
The following commands cannot be used in the same class or policy map with the priority percentage command:
–
–
•
Related Features and Technologies
The distributed Low Latency Queueing feature is related to the following features:
•
•
•
•
•
Related Documents
•
•
•
•
Supported Platforms
•
Supported Standards, MIBs, and RFCs
Standards
None
MIBs
Class-Based Quality of Service MIB
For descriptions of supported MIBs and how to use MIBs, see the Cisco MIB web site on CCO at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
RFCs
None
Prerequisites
To use this feature, you should be familiar with the following:
•
•
•
•
•
•
Configuration Tasks
See the following sections for configuration tasks for the distributed Low Latency Queueing feature. Each task in the list indicates if the task is optional or required.
•
•
•
•
•
Configuring a Priority Queue for an Amount of Available Bandwidth
To give priority to a class based on the amount of available bandwidth within a policy map, use the following commands in the policy map class configuration mode:
The service policy configured in this section is not yet attached to an interface. This command is applied when you attach a service policy to an interface. For information on attaching a service policy to an interface, see the Modular Quality of Service Command-Line Interface document.
Configuring a Priority Queue for a Percentage of Available Bandwidth
To give priority to a class based on a percentage of available bandwidth, use the following commands in policy map class configuration mode:
The service policy configured in this section is not yet attached to an interface. This command is applied when you attach a service policy to an interface. For information on attaching a service policy to an interface, see the Modular Quality of Service Command-Line Interface document.
Configuring a Transmission Ring Limit
To limit the number of allowable particles on a transmission ring on an ATM interface, use the following commands:
To limit the number of allowable particles on a transmission ring on an ATM subinterface, use the following commands:
Verifying Low Latency Queueing
To view the contents of the priority queue (such as queue depth and the first packet queued), use the following commands in EXEC mode:
The priority queue is the queue in which the conversation ID is equal to the number of dynamic queues plus 8. The packets in the priority queue have a weight of 0.
Verifying a Transmission Ring Limit
To see the contents of the interface or the PVC, use the following command in EXEC mode:
Monitoring and Maintaining Low Latency Queueing
To tune your Real-Time Transport Protocol (RTP) bandwidth or to decrease RTP traffic if the priority queue is experiencing drops, use one or more of the following commands:
Configuration Examples
This section provides the following configuration examples:
•
•
•
•
Enabling Priority Queueing for an Amount of Available Bandwidth on an ATM Subinterface
The priority command can be enabled on an ATM subinterface, and that subinterface must have only one enabled ATM PVC. This configuration provides a sufficient amount of ATM PVC support.
In the following example, a priority queue (with a guaranteed allowed bandwidth of 50 kbps) is reserved for traffic that is sent from the source address (10.10.10.10) to the destination address (10.10.10.20), in the range of ports 16384 through 20000 and 53000 through 56000.
First, the following commands configure access list 102 to match the desired voice traffic:
router(config)# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 16384 20000router(config)# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 53000 56000Next, the class map voice is defined, and the policy map policy1 is created; a priority queue for the class voice is reserved (with a guaranteed allowed bandwidth of 50 kpbs and an allowable burst size of 60 bytes), a bandwidth of 20 kbps is configured for the class bar, and the default class is configured for flow-based fair queuing. The service-policy command then attaches the policy map to subinterface atm1/0.1:
router(config)# class-map voicerouter(config-cmap)# match access-group 102router(config)# policy-map policy1router(config-pmap)# class voicerouter(config-pmap-c)# priority 50 60router(config-pmap)# class barrouter(config-pmap-c)# bandwidth 20router(config-pmap)# class class-defaultrouter(config-pmap-c)# fair-queuerouter(config)# interface atm1/0.1router(config-subif)# service-policy output policy1Enabling Priority Queueing for a Percentage of Available Bandwidth on an ATM Subinterface
The priority percent command can be enabled on an ATM subinterface, and that subinterface must have only one enabled ATM PVC. This configuration provides a sufficient amount of ATM PVC support.
In the following example, a priority queue (with a guaranteed allowed bandwidth percentage of 15 percent) is reserved for traffic that is sent from the source address (10.10.10.10) to the destination address (10.10.10.20), in the range of ports 16384 through 20000 and 53000 through 56000.
First, the following commands configure access list 102 to match the desired voice traffic:
router(config)# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 16384 20000router(config)# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 53000 56000Next, the class map voice is defined, and the policy map policy1 is created; a priority queue for the class voice is reserved (with a guaranteed allowed bandwidth percentage of 15 percent), a bandwidth percentage of 20 percent is configured for the class bar, and the default class is configured for flow-based fair queuing. The service-policy command then attaches the policy map to subinterface atm1/0.1:
router(config)# class-map voicerouter(config-cmap)# match access-group 102router(config)# policy-map policy1router(config-pmap)# class voicerouter(config-pmap-c)# priority percent 15router(config-pmap)# class barrouter(config-pmap-c)# bandwidth percent 20router(config-pmap)# class class-defaultrouter(config-pmap-c)# fair-queuerouter(config)# interface atm1/0.1router(config-subif)# service-policy output policy1Limiting the Transmission Ring Limit on an ATM Interface
In the following example, the number of particles on the transmission ring of an ATM interface is limited to seven particles:
router(config)# interface atm 1/0/0router(config-if)# atm pvc 32 0 32 tx-ring-limit 7Limiting the Transmission Ring Limit on an ATM PVC Subinterface
In the following example, the number of particles on the transmission ring of an ATM PVC subinterface is limited to ten particles:
router(config)# interface ATM1/0/0.1 point-to-pointrouter(config-subif)# pvc 2/200router(config-if-atm-vc)# tx-ring-limit 10The tx-ring-limit command can be applied to several ATM PVC subinterfaces on a single interface. Every individual PVC can configure a transmission ring limit.
Command Reference
This section documents the priority and the tx-ring-limit commands. All other commands used with this feature are documented in the Cisco IOS Release 12.1 command reference publications or Cisco IOS Release 12.1 T feature module publications.
priority
To give priority to a class of traffic belonging to a policy map, use the priority policy-map class configuration command. To remove a previously specified priority specified for a class, use the no form of this command.
priority{kbps | percent percent} [bytes]
no priority {kbps | percent percent} [bytes]
Syntax Description
Defaults
No default behavior or values.
Command Modes
Policy map class configuration
Command History
Usage Guidelines
Because 1 percent of the available bandwidth is reserved for the default traffic class, the sum of the percentage for bandwidth and priority percent bandwidth reservations cannot exceed 99 percent.
This command allows users to enable low latency behavior on a per-class basis. Low latency behavior allows delay-sensitive data such as voice to be dequeued and sent first (before packets in other queues are dequeued), giving delay-sensitive data preferential treatment over other traffic.
The priority command allows you to set up classes based on a variety of criteria (not just UDP ports) and assign priority to them, and is available for use on serial interfaces and ATM PVCs.
The default bytes value, which is computed as 200 milliseconds of traffic at the configured kbps rate, is used when the bytes argument is not specified.
The kpbs argument is used to specify the maximum amount of bandwidth allocated for packets belonging to a class configured with the priority command. The kpbs parameter both guarantees bandwidth to the priority class and restrains the flow of packets from the priority class in congestive scenarios.
Priority queues can be reserved by either size or percentage values, but not both, in the same policy map. Therefore, if the priority command is used without the percentage option in a policy map, the bandwidth command, if used, must also be used without the percentage option, and vice versa. Similarly, if the priority percentage command is used in a policy map, the bandwidth percent command must be used to specify bandwidth allocation for the class, and vice versa. The priority and priority percent command can also not be used in the same policy map. For a list of commands that cannot be used in the same policy map with the priority percent command, see the following paragraph.
The bandwidth and priority commands cannot be used together in the same class map. These commands can be used together in the same policy map, however.
The following commands cannot be used in the same policy map with the priority command:
•
•
The following commands cannot be used in the same policy map with the priority percentage command:
•
•
Within a policy map, you can give one or more classes priority status. When multiple classes within a single policy map are configured as priority classes, all traffic from these classes is enqueued to the same, single, priority queue.
When the device is not congested, the priority class traffic is allowed to exceed its allocated bandwidth. When the device is congested, the priority class traffic above the allocated bandwidth is discarded.
Keep the following guidelines in mind when using the priority command:
•
•
•
•
Configuring the priority command in multiple classes provides the ability to police the priority classes individually. For an example, refer to the following configuration:
policy-map policy1class voice1priority 24class voice2priority 48class databandwidth 20In this example, voice1 and voice2 classes of traffic go into the high-priority queue and get priority queueing over data traffic. However, voice1 traffic will be rate-limited to 24 kbps and voice2 traffic will be rate-limited to 48 kbps.
Examples
The following example configures priority queueing with a guaranteed bandwidth of 50 kbps and a one-time allowable burst size of 60 bytes for the policy map policy1:
router(config)# policy-map policy1router(config-pmap)# class voicerouter(config-pmap-c)# priority 50 60In the following example, 10 percent of the available bandwidth is reserved for class voice on interfaces that have attached the policy1 policy map:
router(config)# policy-map policy1router(config-pmap)# class voicerouter(config-pmap-c)# priority percent 10Related Commands
tx-ring-limit
To limit the number of particles that can be used on a transmission ring on the PA-A3 port adapter, use the tx-ring-limit command. To disable the tx-ring-limit command, use the no form of the command.
tx-ring-limit ring-limit
no tx-ring-limit ring-limit
Syntax Description
ring-limit
Specifies the maximum number of allowable particles that can be placed on the transmission ring.
Defaults
No default behavior or values.
Command Modes
ATM Interface Configuration
ATM Subinterface Configuration
Command History
Usage Guidelines
This command can only be used on a PA-A3 port adapter.
The transmission ring limit value is limited to values that are between 3 and 6000.
Examples
The following example configures the transmission ring limit to seven particles on an ATM interface:
router(config)# interface atm 1/0/0router(config-if)# atm pvc 32 0 32 aal5snap 10000 8000 2000 tx-ring-limit 7The following example configures the transmission ring limit to ten particles on an ATM PVC subinterface:
router(config)# interface ATM1/0/0.1 point-to-pointrouter(config-subif)# pvc 2/200router(config-if-atm-vc)# tx-ring-limit 10Related CommandsReated
Glossary
CBWFQ—Class-Based Weighted Fair Queueing. Extends the standard WFQ functionality to provide support for user-defined traffic classes.
Class-Based Weighted Fair Queueing—See CBWFQ.
LLC—logical link control. Higher of the two data link layer sublayers defined by the IEEE. The LLC sublayer handles error control, flow control, framing, and MAC-sublayer addressing. The most prevalent LLC protocol is IEEE 802.2, which includes both connectionless and connection-oriented variants.
logical link control—See LLC.
PPP—Point-to-Point Protocol. Successor to SLIP that provides router-to-router and host-to-network connections over synchronous and asynchronous circuits. Whereas SLIP was designed to work with IP, PPP was designed to work with several network layer protocols, such as IP, IPX, and ARA. PPP also has built-in security mechanisms, such as CHAP and PAP. PPP relies on two protocols: LCP and NCP.
Random Early Detection—See RED.
RED—Random Early Detection. A congestion avoidance mechanism that takes advantage of TCP's congestion control mechanism. By randomly dropping packets prior to periods of high congestion, RED tells the packet source to decrease its transmission rate. Assuming the packet source is using TCP, it will decrease its transmission rate until all the packets reach their destination, indicating that the congestion is cleared.
RTP—Real-Time Transport Protocol. One of the IPv6 protocols. RTP is designed to provide end-to-end network transport functions for applications sending real-time data such as audio, video, or simulation data over multicast or unicast network services. RTP provides services such as payload type identification, sequence numbering, time-stamping, and delivery monitoring to real-time applications.
SNA—Systems Network Architecture. Large, complex, feature-rich network architecture developed in the 1970s by IBM. Similar in some respects to the OSI reference model, but with a number of differences.
UDP—User Datagram Protocol. Connectionless transport layer protocol in the TCP/IP protocol stack. UDP is a simple protocol that exchanges datagrams without acknowledgments or guaranteed delivery, requiring that error processing and retransmission be handled by other protocols. UDP is defined in RFC 768.
weighted fair queueing—See WFQ.
WFQ—weighted fair queueing. Congestion management algorithm that identifies conversations (in the form of traffic streams), separates packets that belong to each conversation, and ensures that capacity is shared fairly between these individual conversations. WFQ is an automatic way of stabilizing network behavior during congestion and results in increased performance and reduced retransmission.
