When using the priority percent and bandwidth percent commands in a QoS policy-map, the priority percent option reserves a certain percentage of an interface's bandwidth, but also limits it to that bandwidth. Any of that priority traffic that exceeds its reserved bandwidth may be dropped. On the other hand, non-priority traffic that has bandwidth reserved with the bandwidth percent command is allowed to exceed that reserved bandwidth limit.
Why is that? Isn't it likely that your priority traffic might be your most important, or at least the kind of traffic that isn't tolerant of drops, such as real-time voice or video? Why would Cisco put that limitation on the priority percent command?
"During congestion conditions, the traffic class is guaranteed bandwidth equal to the specified rate. (Recall that bandwidth guarantees are only an issue when an interface is congested.) In other words, the priority command provides a minimum bandwidth guarantee.
In addition, the priority command implements a maximum bandwidth guarantee. Internally, the priority queue uses a token bucket that measures the offered load and ensures that the traffic stream conforms to the configured rate. Only traffic that conforms to the token bucket is guaranteed low latency. Any excess traffic is sent if the link is not congested or is dropped if the link is congested. For more information, refer to What Is a Token Bucket?. "
"The purpose of the built-in policer is to ensure that the other queues are serviced by the queueing scheduler. In the original Cisco priority queueing feature, which uses the priority-group and priority-list commands, the scheduler always serviced the highest priority queue first. In extreme cases, the lower priority queues rarely were serviced and effectively were starved of bandwidth.
The real benefit of the priority command—and its major difference from the bandwidth command—is how it provides a strict de-queueing priority to provide a bound on latency. Here is how the Cisco IOS Configuration Guide describes this benefit: "A strict priority queue (PQ) allows delay-sensitive data such as voice to be de-queued and sent before packets in other queues are de-queued....."
First please note that with LLQ non-priority traffic cannot take bandwidth reserved for priority traffic. With that said the reason why the priority traffic cannot exceed is to protect the non-priority traffic. If priority traffic were allowed to exceed a scenario could exist where non-priority traffic would all be dropped as the priority traffic is serviced.
Cisco's implementation of priority queuing (PQ) actually does just that. It will starve or deny service to lower priority traffic for the sake of high priority traffic.
Just to back up Ryan's input (Well put Ryan +5)
Have a look at this link which discusses the comparisions between PRIORITY & BANDWIDTH QOS settings
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Just wanted to clarify a few points noted by the other posters.
The implicit LLQ policer only engages when there's congestion so it's possible for LLQ to use more than the bandwidth specified.
Classes can use bandwidth not being used by other classes, including LLQ. In other words, if 20% is defined for LLQ, but not being used, other classes can use this bandwidth.
Thanks for the responses, but my question was why is the priority queue bandwidth-restricted, whereas the bandwidth classes are not?
If I say to my customers - "We'll put your voice traffic in a Low-Latency queue and reserve 20% of the circuit bandwidth for it, but if it exceeds that bandwidth (during periods of congestion), it will be dropped" - they'll probably ask, "Why are we putting our voice traffic in a queue that may drop the traffic?"
I assume there's some technical justification for it. I'd just ike to know what that justification is...