Cisco QoS - Low Latency Queuing

Class based weighted fair queuing (CB-WFQ) was initially released without the support of a priority queuing (PQ) system. Although real-time voice and video applications could receive bandwidth reservations in the CB-WFQ system, the system could not guarantee the delay and jitter (delay variation) requirements of real-time, interactive voice and video conversations. To address this need, Cisco soon unveiled a new system called low latency queuing (LLQ) that used the same modular QoC CLI (MQC) approach as CB-WFQ. Cisco documentation sometimes refers to LLQ as the following formula: PQ + CB-WFQ. Cisco added priority queuing support to the MQC to provide the following three guarantees: • Packet loss • Delay • Jitter The bandwidth guarantees of the CB-WFQ system only guarantee packet loss. CB-WFQ guarantees are provisioned with the bandwidth command, while the PQ system is configured with the priority command. The PQ has different behavior characteristics than the CB-WFQ guarantees that deserve some time and attention. I will talk to the following bandwidth guarantee example that was used in the last blog: Policy-map test-policy Class FTP Bandwidth percent 10 Class HTTP Bandwidth percent 20 ! Interface Serial 0/0/0 Bandwidth 1536 service-policy output test-policy This QoS policy guarantees a certain amount of bandwidth to FTP and HTTP traffic during periods of congestion. When there is no congestion on the T1 link, either application class can use the entire available 1.536Mbps. During periods of congestion, FTP traffic is only guaranteed 153.6kbps (router will round the bandwidth number to the next highest increment of 8kpbs – 160kbps). FTP could transmit at much higher rates however because there is no limit on the FTP traffic. Policing and shaping technologies set a ceiling or maximum bandwidth, while the bandwidth command configures minimum guarantees. FTP and HTTP traffic will always receive an amount of bandwidth higher than the bandwidth statement unless the QoS policy provisions 100% of the bandwidth and there is high congestion on the output interface. Both CB-WFQ and LLQ policies can only be applied to egress (output) interfaces. Only classification, marking, and policing technologies can be used on ingress (input) to Cisco routers. The priority queue (PQ) is implicitly policed on the Cisco routers. If voice over IP was added to our policy from the previous page, the configuration changes to the policy would be similar to the following: Policy-map test-policy Class voice priority 264 ! Interface Serial 0/0/0 service-policy output test-policy The PQ will never be able to forward traffic over 264kbps. If there is no congestion on the output interface, the policy will limit voice traffic to 264kbps. I chose this number with the assumption that the customer was sending up to 10 G.729 voice calls over a PPP link. The audio codec is 8kbps, 16kbps for layer 3 and 4 overhead (IP/UDP/RTP), and 2.4kbps for the layer 2 PPP overhead. See my previous blog for more detailed information on the sizing of voice calls. The priority queue does include a small burst interval that is automatically configured based on a 200ms burst interval of the configured bandwidth. The bust usually accommodates for the layer 2 overhead if this was not calculated. The layer 2 overhead of ATM cells may be much larger than the automatically configured burst size. A default voice sample rate of 20ms results in a high cell tax (overhead) when using ATM cell-based services. Although the priority command can be used in multiple policy-map classes, there is only one Priority queue in the L3 software queuing system. Version 3.3 of Cisco’s QoS SRND recommends the allocation of no more than 33% of the interface bandwidth to the priority queue to ensure other application classes get a fair share of the available bandwidth. The 33% recommendation is very generic and can be exceeded on an as needed basis. The Telepresence SRND (2.0) describes situations where much higher bandwidth values can be allocated to the priority queue on an as needed basis. The following policy map configures one priority queue that is 724kbps in size, but the voice class will be implicitly policed to 264kbps and the video class 460kbps. The video class was sized based on one H.264 video call (384kbps) and 20% overhead. Policy-map test-policy Class voice Priority 264 Class video Priority 460 The next blog will continue our coverage of LLQ and the MQC. We will discuss the processing order of the policy-map, and the class-default. REFERENCES Cisco Feature Navigator

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Now read: Getting grounded in IoT