How does policing the LLQ prevent queue starvation?

[Mitrixsen]

Hello, everyone.

I've read that an LLQ can starve out other queues. So for this reason, we can set a limit on it so anything exceeding this limit can be dropped or put to the normal queues.

However, I don't quite understand how limiting the LLQ can prevent queue starvation. So we limit the amount of packets in the priority queue. However, if we're constantly receiving packets like VOIP which fills up the queue, won't the scheduler always try to empty the priority queue before moving onto the other queues? So what exactly have we solved here? Or am I misunderstanding somethng here?

Even if you're limited, you can still be receiving a continuous stream of packets that can fill up the queue thus starving everyone out, or not?

Thank you.

David

[M02@rt37]

Hello @Mitrixsen 

Limiting the LLQ prevents starvation of other queues by enforcing a maximum bandwidth (or rate...) the priority queue can consume, even if it receives a continuous stream of high-priority packets like voip. This limit ensures that once the LLQ has transmitted up to its allowed bandwidth within a given interval, any excess traffic is either dropped or treated as regular traffic and placed in lower-priority queues. While the scheduler prioritizes the LLQ, this mechanism guarantees it cannot monopolize the link, leaving bandwidth for other queues. Thus, even with constant high-priority traffic, the LLQ is constrained by its limit, ensuring fairness and preventing starvation of lower-priority traffic while still protecting latency-sensitive flows within the defined bandwidth.

[Mitrixsen]

Thank you for the response.

I understand how LLQ and policing works and what it aims to achieve but I don't understand how setting such a limit prevents the starvation. We do limit the amount of packets in the queue but that doesn't change the fact that if an LLQ fills up, the scheduler will always try to empty it first before moving onto anything else.

David

[M02@rt37]

Setting a policing limit on LLQ helps prevent starvation by controlling how much bandwidth LLQ can use. Without a policing limit, LLQ can consume all available bandwidth, especially if there is a continuous flow of high-priority traffic like voip, leading the scheduler to prioritize it and potentially starving other queues. By applying a policing limit, LLQ is restricted to a specified percentage of the bandwidth (e.g., 30%), and once this limit is reached, any excess traffic is either dropped or moved to lower-priority queues. This ensures that the remaining bandwidth is available for other traffic, preventing lower-priority queues from being starved. Essentially, policing balances the need for high-priority traffic while ensuring that other traffic types still have the opportunity to be processed, maintaining fairness and network stability.

[Joseph W. Doherty]

Did you miss my prior reply, or not understand its significance?

If the latter, the LLQ will not fill up because only 30% (if that's the allocation) are accepted by the class, and they are dequeued before other traffic  Since there's ample bandwidth to actually transmit the accepted 30%, the LLQ will usually show very few, if not zero, packets.

BTW, I recall Cisco recommending not providing LLQ more than about a third of the bandwidth, to provide adequate bandwidth for the non-LLQ classes.  IMO, that's cow chips, as bandwidth needs of the non-LLQ depends on their needs, although Cisco might have in mind the variable impact to performance a large LLQ allocation can cause.

However, if LLQ doesn't have headroom, it can self queue, which can be detrimental to the traffic.  As a general guide, one third or less, usually causes little queuing.  Up to half usually minimal queuing.  From half to about two thirds we have some to moderate queuing but above two thirds, we may have lots of queuing.  (The prior is based on simple queuing theory.)

[MHM Cisco World]

It not prevent starvation it only make SW drop low priority packet' and keep high priority packet such as control and  voip.

MHM

[M02@rt37]

Not quite. While it’s true that limiting the LLQ will drop packets exceeding the configured bandwidth, the primary goal of the limit isn’t just to prioritize higher-priority traffic like VoIP or control packets; it’s to enforce fairness among all traffic classes.

Without a limit, the LLQ could monopolize the link during congestion, starving other queues. By capping the LLQ’s bandwidth, the scheduler ensures that once the LLQ’s limit is reached, other queues have guaranteed time to transmit their packets. While excess LLQ packets might be dropped, this mechanism prevents starvation of lower-priority queues, ensuring a balanced and fair allocation of link resources. So, it’s not only about dropping packets—it’s about ensuring the LLQ doesn’t consume all the bandwidth.

[Joseph W. Doherty]

---

@MHM Cisco World wrote:

It not prevent starvation it only make SW drop low priority packet' and keep high priority packet such as control and  voip.

MHM

---

That would be true if you could assign LLQ 100%, but don't recall if you can.

PS:

From CML, on a IOSV router:

policy-map test
class class-default
priority percent 100

But, I cannot allocate any other classes, as there's no bandwidth available for them.

"Sum total of class bandwidths exceeds 100 percent"

[Joseph W. Doherty]

But, if LLQ policing drops packets before they are added to its queue, then what happens?