Shape average percent 100

[Clutz5250]

I'd like some clarity on this configuration statement, particularly when set at percent 100. It's been my understanding that you would utilize this along with bandwidth statement set on the interface (if CIR is different than interface) and it would be better practice to set at ~ 85 or 90 average percent of bandwidth, allowing for a better shaping wave.

Assuming there is CBWFQ (say a standard QoS 4/5 model) and WRED setup for a few queues, and the interface matches the CIR, then it would seem to me there would be more back pressure with shape average percent 100 and less benefit of the queuing mechanisms and adding to delay. What i mean is that it would seem more and more traffic would hit line rate with shape average percent 100 and thus plateaus are more often/worse in the traffic patterns. Whereas if you set shape average percent 90, it allows for bursting and less important traffic has more of a chance, and maybe less buffering overall. This burst would be artificial since its under interface rate / CIR too.

Thinking the average syntax is the thing I may not understand here. Or maybe i do understand it and I'm just over here doubting myself.

Thanks in advance for any input anyone cares to share!

[Joseph W. Doherty]

The only reason I could think to use 100% shaping value is to match a bandwidth statement which is less than port bandwidth, i.e. to match a CIR less than port bandwidth.

Don't understand your "shaping wave", especially in regard to setting to 85 or 90 percent.

However, I often do recommend setting a shaper's bandwidth to 85 or 90 percent of CIR because, at least in the past, I believe many Cisco shapers didn't account for L2 overhead, and, in my experience, L2 overhead often accounted for 10 to 15% of bandwidth consumption.  I also believe some of Cisco (later) shapers do account for L2 overhead, which would be very nice, because the L2 overhead percentage differs much based on packet's size.

"Average" shaping tries to simulate that amount of physical bandwidth.

The alternative to "average" shaping has been "peak" shaping, which in theory, allows a short term burst, which is recharged/credited when actual usage is less than "average".  However, in the past, it appears many Cisco devices just recharge the peak value every Tc even if there was no unused bandwidth.  I.e. "peak" on those platforms usually sustained 2x the bandwidth setting.

BTW, in the full context of QoS, I cannot think of any reason to artificially reduce overall bandwidth that's available.

Shaping is generally used where downstream of your interface there's some bottleneck with less bandwidth, but if you cannot manage the bottleneck at the bottleneck, you can simulate it upstream, with a shaper, where you can manage the simulated bottleneck.  If you have no interest in management of the bottleneck, there's no need to shape upstream for it.

I'm guessing from your posting, you have some interest in QoS, correct?  Unfortunately, I've rarely found any QoS material that really explains it well, or does it well, except for insuring extremely sensitive traffic, like VoIP, isn't degraded.  So, if you have more questions, fell free to post them.