QoS Queue Design for VoIP: LLQ, Priority Queues, and Policing

You dial a number. You hear static. Then silence. It’s frustrating, but the culprit isn’t usually your phone or the internet connection itself. It’s likely the way your network handles data packets. Voice over IP (VoIP) is unforgiving. Unlike email or web browsing, which can handle a few seconds of delay without you noticing, voice requires near-instant delivery. If packets arrive late or out of order, the call quality degrades instantly.

To fix this, network engineers use Quality of Service (QoS). Specifically, they rely on a combination of Low Latency Queuing (LLQ, a queuing mechanism that provides strict priority to delay-sensitive traffic like VoIP while using policing to prevent starvation of other classes), strict priority queues, and traffic policing. This setup ensures voice packets get a "VIP lane" through your network routers and switches, bypassing the traffic jams caused by heavy data downloads or video streaming.

The Problem with Standard Queuing

Imagine a single-lane road where cars (data packets) line up behind each other. In a standard network setup using First-In-First-Out (FIFO) queuing, every packet waits its turn regardless of what it carries. A massive file download might clog the queue, causing small, critical voice packets to wait too long. By the time those voice packets are sent, they are often useless because the conversation has moved on.

Even more advanced methods like Weighted Fair Queuing (WFQ) or Class-Based Weighted Fair Queuing (CBWFQ, a Cisco queuing method that allocates bandwidth to different traffic classes based on weights, ensuring fair sharing but not strict priority) help by giving certain types of traffic a guaranteed slice of the pie. However, CBWFQ still processes traffic in cycles. Even if voice gets a high weight, it might still have to wait for a large data packet to finish sending before it can start. That tiny wait-measured in milliseconds-is enough to cause jitter and choppy audio.

How LLQ Solves the Delay Issue

Low Latency Queuing (LLQ) was introduced by Cisco in the early 2000s as an enhancement to CBWFQ. It solves the waiting problem by adding a strict priority queue. Think of it like an ambulance on a highway. The ambulance doesn't wait in traffic; it moves to the front and goes first. In LLQ, the router checks the priority queue first. If there are voice packets there, it sends them immediately, bypassing all other queues entirely.

This strict priority scheduling drastically reduces latency and jitter. For VoIP, this is non-negotiable. Human ears detect delays greater than 150 milliseconds as noticeable lag. LLQ keeps voice latency well below that threshold, even when the network link is congested with bulk data transfers.

The Danger of Unchecked Priority

If strict priority sounds perfect, why don't we just put everything in the priority queue? The answer is starvation. If you allow the priority queue to grow too large, it will consume all available bandwidth. Data traffic, email, and web browsing would be starved completely, leading to a frozen screen or dropped connections for non-voice applications.

This is where policing comes in. LLQ isn't just a priority queue; it's a priority queue with a built-in speed limit. The "priority" command in Cisco IOS configures both the guarantee and the cap. For example, if you configure `priority percent 10`, you are telling the router:

• Always send voice packets first.
• But never let voice traffic exceed 10% of the total link bandwidth.

If the voice traffic stays under that 10%, it flows freely. If it exceeds it, the integrated policer drops the excess packets. This ensures that while voice gets the best treatment, the rest of the network remains functional.

Policing vs. Shaping: Why We Drop Packets for Voice

In network design, you have two main tools to control traffic rates: policing and shaping. They achieve similar goals but behave very differently.

Shaping buffers excess traffic. If traffic exceeds the rate, the shaper holds the extra packets in memory and sends them later when the line is free. This smooths out bursts but introduces delay. Since VoIP hates delay, shaping is generally a bad idea for voice streams themselves. Holding a voice packet for even a fraction of a second makes it obsolete.

Policing is stricter. If traffic exceeds the configured rate, the policer drops the excess packets immediately. While dropping packets sounds terrible, it's actually better for real-time media than delaying them. A dropped packet causes a brief glitch or silence, which humans tolerate better than echo or severe lag caused by buffering. Therefore, LLQ uses policing to cap the priority queue, ensuring low latency at the cost of potential packet loss during extreme congestion.

Design Rules for LLQ Implementation

Getting LLQ right requires careful planning. Here are the core rules established by industry standards and Cisco design guides:

1. Separate Voice and Video: Don't mix interactive voice and video into the same LLQ class. Video is less sensitive to jitter than voice but consumes more bandwidth. If you combine them, a burst of video traffic could trigger the policer and drop voice packets. Create separate priority queues for each.
2. Calculate Bandwidth Accurately: You must account for Layer 2 overhead. A G.711 codec generates 64 kbps of voice data, but with Ethernet headers, IP headers, and RTP headers, the actual packet size is closer to 86 kbps per call. Size your LLQ bandwidth to accommodate the expected number of simultaneous calls plus this overhead.
3. Use Call Admission Control (CAC): LLQ policing should rarely drop packets under normal conditions. CAC prevents new calls from being set up if the LLQ bandwidth is already full. This stops the policer from having to do its job by limiting the load at the source.
4. Apply Policies at the Edge: Implement QoS policies on the WAN edge interfaces where congestion is most likely to occur. Inside a fast campus LAN, you usually don't need strict priority queuing because links are rarely saturated.

Troubleshooting Common LLQ Issues

Even with a solid design, things can go wrong. The most common issue is mis-sizing the LLQ bandwidth. If you allocate too little bandwidth, the policer will drop voice packets during peak hours, resulting in choppy audio. If you allocate too much, you risk starving data traffic, causing slow file transfers and sluggish applications.

Another frequent mistake is failing to mark traffic correctly. LLQ relies on DSCP markings (specifically EF for Expedited Forwarding) or IP Precedence to identify voice packets. If your phones aren't marking packets, or if intermediate devices strip these marks, the voice traffic falls into the default best-effort queue and loses its priority status. Always verify markings at the ingress point of your network.

Finally, monitor your policer statistics. Use commands like `show policy-map interface` to check if the LLQ class is dropping packets. If you see drops, either increase the LLQ bandwidth allocation or tighten your Call Admission Control limits to prevent too many concurrent calls.

Future Outlook for VoIP QoS

As of 2026, LLQ remains the gold standard for enterprise VoIP deployments. While software-defined networking (SDN) and automation are changing how we deploy configurations, the underlying mechanics of priority queuing and policing haven't changed. Voice still needs low latency, and data still needs fairness. LLQ provides that balance efficiently. Newer technologies focus on automating the provisioning of these queues rather than replacing the concept itself.