cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1903
Views
10
Helpful
10
Replies

Justification for bandwidth limit when using the QoS priority percent command

pweinhold
Beginner
Beginner

Hi,

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?

Thanks.

10 Replies 10

cflory
Beginner
Beginner

From:

http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a0080103eae.shtml#configuringthebandwidthcommand

"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....."

HTH!

-Chris

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.

Regards,

Ryan

Hi,

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

http://www.cisco.com/en/US/partner/tech/tk543/tk757/technologies_tech_note09186a0080103eae.shtml

Regards

Alex

Regards, Alex. Please rate useful posts.

Joseph W. Doherty
Hall of Fame Master Hall of Fame Master
Hall of Fame Master

Disclaimer

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.

Liability Disclaimer

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.

Posting

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.

Hi,

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...

Thanks.

Ryan Newell