Content

| 8.6 |  | Congestion Avoidance |
| 8.6.6 |  | Low Latency Queuing (LLQ) |

The LLQ feature brings strict Priority Queuing (PQ) to CBWFQ. Strict PQ allows delay-sensitive data such as voice to be sent before packets in other queues are sent. Without LLQ, CBWFQ provides WFQ based on defined classes with no strict priority queue available for real-time traffic. For CBWFQ, the weight for a packet belonging to a specific class is derived from the bandwidth assigned to the class. Therefore, the bandwidth assigned to the packets of a class determines the order in which packets are sent. All packets are serviced fairly based on weight and no class of packets may be granted strict priority. This scheme poses problems for voice traffic that is largely intolerant of delay, especially variation in delay. For voice traffic, variations in delay introduce irregularities of transmission manifesting as jitter in the heard conversation. LLQ provides strict priority queuing for CBWFQ, reducing jitter in voice conversations.

LLQ enables the use of a single, strict priority queue within CBWFQ at the class level. Any class can be made a priority queue by adding the priority keyword. Within a policy map, one or more classes can be given priority status. When multiple classes within a single policy map are configured as priority classes, all traffic from these classes is sent to the same, single, strict priority queue.

Although it is possible to queue various types of real-time traffic to the strict priority queue, it is strongly recommend that only voice traffic be sent to it because voice traffic is well-behaved, whereas other types of real-time traffic are not. Moreover, voice traffic requires that delay be non-variable in order to avoid jitter. Real-time traffic such as video could introduce variation in delay, thereby thwarting the steadiness of delay required for successful voice traffic transmission.

When the priority command is specified for a class, it takes a bandwidth argument that gives maximum bandwidth in kbps. This parameter specifies the maximum amount of bandwidth allocated for packets belonging to the class configured. The bandwidth parameter both guarantees bandwidth to the priority class and restrains the flow of packets from the priority class. In the event of congestion, policing is used to drop packets when the bandwidth is exceeded.

Voice traffic queued to the priority queue is UDP-based and therefore not adaptive to the early packet drop characteristic of WRED. Because WRED is ineffective, the WRED random-detect command cannot be used with the priority command. In addition, because policing is used to drop packets and a queue limit is not imposed, the queue-limit command cannot be used with the priority command.