topic QOS question Shape peak and Shape average in Routing and SD-WAN

QOS question Shape peak and Shape average

svaishya20 — Mon, 04 Mar 2019 22:35:56 GMT

Hi,

Can any one please explain what is the difference between shape average and shape peak in QOS.

From my understanding shape average is CIR and shape peak is max BW of link.

so is it possible if link bandwith is 64K then we can allocate shape average 256k.

Thanks

Saurabh

QOS question Shape peak and Shape average

Peter Paluch — Mon, 12 Dec 2011 06:39:04 GMT

Hello,

The shape peak replenishes both Bc and Be tokens every Tc seconds, and allows for sending at higher sustained rate that depends both on the size of Bc and Be. If only the Bc tokens were replenished, the sustained rate would be

CIR = Bc/Tc

With both Bc and Be tokens being replenished in shape peak, the sustained rate is

CIR' = (Bc+Be)/Tc

Expressing Tc from the first equation yields Tc=Bc/CIR, and using it in the second equation yields:

CIR' = (Bc+Be) / (Bc / CIR)=(Bc+Be) * CIR / Bc = CIR * (1 + Be/Bc)

This is the speed as indicated in the Command Reference for the shape peak command:

http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_s1.html#wp1074988

The shape average replenishes only the Bc tokens every Tc seconds, and hence the sustained rate is simply CIR=Bc/Tc. After periods of longer inactivity, the burst may grow up to Bc+Be bytes but it is not sustainable.

To compare:

The sustained rate in shape average is equal to CIR=Bc/Tc (the CIR is a part of the configuration command)
The sustained rate in shape peak is equal to CIR'=CIR * (1 + Be/Bc) (the CIR is a part of the configuration command)
Both models allow for bursting up to Bc+Be

In default configuration, Be=Bc, therefore with shape peak, the CIR'=CIR*(1+Bc/Bc)=CIR*(1+1)=2*CIR, i.e. the shape peak would result into shaping on a doubled sustained rate than the shape average command.

Best regards,

Peter

QOS question Shape peak and Shape average

svaishya20 — Mon, 12 Dec 2011 10:30:36 GMT

Hi Peter,

Thanks for replying.

i saw the link so peak rate is having higer capabilty to send data.

So if i have link of 64k then can i configure 256k of shape average.

from cisoc link-

Average rate shaping limits the transmission rate to the CIR. Using the CIR ensures that the average amount of traffic being sent conforms to the rate expected by the network.

If the link is having bw of 64K then how can it provide bw of 256k.

and if i have a link of 256 K then how can i calculate bc and be value

Please clarify

QOS question Shape peak and Shape average

Peter Paluch — Mon, 12 Dec 2011 10:45:05 GMT

Hi Saurabh,

peak rate is having higer capabilty to send data.

Well, shape peak allows you to continuously send data in excess of configured CIR by utilizing both Bc and Be burst sizes when scheduling the transmission. Whether that is acceptable by your provider is another issue - he may police you on the level of the CIR and the excess traffic you send will be dropped. You always have to think about the fact that not only you are pacing your packets, also your provider is, and if you exceed the contract with your provider, the packets may get remarked or dropped.

So if i have link of 64k then can i configure 256k of shape average.

If the link is 64k then you'll never get more than 64k out of it. Configuring the shaping to 256k would exceed that link's capacity by four times.

Regardless of the shape average or shape peak, the link must provide an equal or higher transmission capacity than the resulting rate of these commands.

If the link is having bw of 64K then how can it provide bw of 256k.

It can not It is just the changed algorithm of shape peak that allows to send data at a rate higher than the configured CIR but whether the link can carry that much data is up to you to verify.

and if i have a link of 256 K then how can i calculate bc and be value

These values are usually determined by a contract with your provider and are configured, not computed. In fact, you configure the CIR and you may configure the Bc and Be.

Best regards,

Peter

QOS question Shape peak and Shape average

svaishya20 — Mon, 12 Dec 2011 12:36:52 GMT

Thanks Peter for explaining so nicely.

I have to configure qos on link of 256K link. and its carrying multicast data snd PDf file also.

So I have to configure in the way when PDf file are also flowing it wont consume whole BW because its like brusty traffic.

i am thinking to configure it throught CBFQ and want to assign more bandwidth to multicast traffic.

and shape average of 128k.

Do i also need to use DSCP value like AF1... value.

thanks

Saurabh

QOS question Shape peak and Shape average

Joseph W. Doherty — Mon, 12 Dec 2011 19:53:12 GMT

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

If you have a device that support CBWFQ, instead of shaping you might find "guaranteeing" a certain amount of bandwidth to certain classes of traffic a better solution. This because shaping limits bandwidth utilization even if excess bandwidth is available.

Re: QOS question Shape peak and Shape average

Joseph W. Doherty — Mon, 12 Dec 2011 20:51:01 GMT

Disclaimer

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 Authorhas been advised of the possibility of such damage.

Posting

I thought Cisco peak shaper and policers only replenished at the CIR rate, i.e. either could allow a burst, if excess credits were available, but peak rate would not be sustained.

"When the excess burst (Be) is configured to a value different than 0, the shaper allows tokens to be stored in the bucket, up to Bc + Be. The largest value that the token bucket can ever reach is Bc + Be, and overflow tokens are dropped. The only way to have more than Bc tokens in the bucket is to not use all Bc tokens during one or more Tc. Since the token bucket is replenished every Tc with Bc tokens, you can accumulate unused tokens for later use up to Bc + Be." (from: http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800a3a25.shtml)

Re: QOS question Shape peak and Shape average

Peter Paluch — Mon, 12 Dec 2011 22:33:33 GMT

Hello Joseph,

I am glad you joined this discussion. I believe this thread is more cut out for you than for me.

I thought Cisco peak shaper and policers only replenished at the CIR  rate, i.e. either could allow a burst, if excess credits were available,  but peak rate would not be sustained.

With regard to shapers in particular, I am quite certain that things work as I've described earlier. The document at

http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfpolsh.html#wp1004234

states:

The Be size allows more than the Bc size to be sent during a time interval under certain conditions. Therefore, DTS provides two types of shape commands: average and peak. When shape average is configured, the interface sends no more than the Bc size for each interval, achieving an average rate no higher than the CIR. When the shape peak command is configured, the interface sends Bc plus Be bits in each interval.

Sadly, the newer QoS Configuration Guides seem to silently omit this description.

This behavior is also described in Odom's and Cavanaugh's book Cisco QoS Exam Certification Guide, page 379:

When you use the peak option, CB Shaping changes how it decides if a packet conforms to or exceeds the traffic contract. As a reminder, using the Shaping logic covered so far in this chapter, Bc bits are sent each Tc. If there’s been a period of low or no activity, and the Shaper has been configured with a Be value, then for a short time, more than Bc can be sent—specifically, Be more. With shape peak, the shaper allows Bc and Be bits to be sent in each interval, even if there has not been a period of little or no activity. In effect, shape peak means that the shaper actually shapes assuming you can send the configured burst during every time period.

Best regards,

Peter

Re: QOS question Shape peak and Shape average

Joseph W. Doherty — Tue, 13 Dec 2011 01:36:45 GMT

Disclaimer

Liability Disclaimer

Posting

Peter what you've posted doesn't make clear credit/token replenishment (unless I've missed it).

I agree peak can send more than CIR during a Tc, the combination of Bc and Be, but if Be has no credits/tokens, effectively your long term rate become just average CIR rate.

Ideally, peak makes sense if only Bc is replenished each Tc. Then Be allows you to gain credit for unused bandwidth yet your long term usage won't really be much more than an average CIR. (This can be really important on policiers, less so on shapers.)

That stated, I do have some hazy recollection of doing some test years ago where I recall 2x average delivered the same overall bandwidth as 1x peak, as you believe it does. Yet, this is one of those features which sometimes seems to be especially sensitive to IOS version and/or platform. For example, your reference link is to DTS, and the old 7500's VIP QoS had many features unavailable on most other router platforms (although HQF QoS greatly minimized the feature differences).

If you have the time and equipment, you might want to try both average and peak shaping and policing, and see if there's any substantial difference if you send at CIR plus a little more, maybe say 10%.

Re: QOS question Shape peak and Shape average

Peter Paluch — Tue, 13 Dec 2011 11:10:04 GMT

Joseph,

Peter what you've posted doesn't make clear credit/token replenishment (unless I've missed it).

Hmmm, I see your point. You are not asking about the possibility of sending Bc+Be bits/bytes every Tc seconds, you are asking about replenishing the Bc/Be tokens.

I will have to test this in a lab. In the meantime, would you care to explain your personal take on the difference between shape average and shape peak, considering the fact that I can set a non-zero Bc+Be for both modes? I.e., how do you see the following two commands differ:

shape average 256000 8000 8000

shape peak 256000 8000 8000

Thank you!

Best regards,

Peter

Re: QOS question Shape peak and Shape average

Joseph W. Doherty — Tue, 13 Dec 2011 17:58:40 GMT

Disclaimer

Liability Disclaimer

Posting

Shape average should restrict transmitted data to the defined bandwidth per Tc. With a shaper, excess will be queued and the excess will be dequeued if the offered rate is less than the CIR. The combination of less than CIR offered rate plus dequeued data will still not exceed CIR.

Shape peak should allow up to Bc+Be per Tc. Be, can store unused Bc credit.

For example, assume we start with a "clean slate" and offer 300 Mbps 1st Tc.

Shape average will xmit 250 Mbps and queue 50 Mbps (NB: actually shaping is impacted by packet sizes, but let's ignore that).

Shape peak will xmit 300 Mbps and decrement 50 Mbps from Be (leaving 200 Mbps credit).

2nd Tc, 350 Mbps is offered.

Shape average will xmit 250 Mbps, 1st the queued 50 Mbps, then the 200 Mbps of the offered and queue 150 Mbps of the offered (150 Mbps in queue [50-50+150])

Shape peak will xmit 350 Mbps and decrement 100 Mbps from Be (leaving 100 Mbps credit).

3rd Tc, 500 Mbps is offered.

Shape average will xmit 250 Mbps, 1st the queued 150 Mbps, then 100 Mbps of the offered and queue 400 Mbps of the offered. (400 Mbps in queue [150-150+400])

Shape peak will xmit 350 Mbps, decrement 100 Mbps from Be (leaving 0 Mbps credit) and queue 150 Mbps.

4th Tc, 200 Mbps is offered.

Shape average will xmit 250 Mbps, 250 Mbps from queue, queue 200 Mbps of the offered, leaving 350 Mbps queued. ([400-250+200])

Shape peak will xmit 250 Mbps, 150 Mbps from queue, 100 Mbps from offered, and add 100 Mbps to queue (leaving 100 Mbps in queue).

5th Tc, 0 Mbps is offered.

Shape average will xmit 250 Mbps, 250 Mbps from queue, leaving 100 Mbps queued. (350-250+0)

Shape peak will xmit 100 Mbps, 100 Mbps from queue and increment Be by 150 Mbps (leaving 150 Mbps credit).

PS:

Hope I got my math right

QOS question Shape peak and Shape average

svaishya20 — Wed, 14 Dec 2011 04:40:06 GMT

Hi Joseph,

thanks for expalining it

I did not understand from here

Shape peak will xmit 300 Mbps and decrement 50 Mbps from Be (leaving 200 Mbps credit).

and second thing I want to ask you guys - If you see from configuration below

class-map match-all Netman

match access-group name QoS-Netman

class-map match-all Trading

match access-group name QoS-Trading

policy-map VPN-CHILD-POLICY

class Trading

set ip dscp af31

bandwidth 200

class Netman

set ip dscp af42

bandwidth 16

class class-default

set ip dscp af21

bandwidth 40

random-detect dscp-based

policy-map VPN-POLICY

class class-default

shape average 256000

service-policy VPN-CHILD-POLICY

interface Serial0/0

description - 64Kb MPLS,

bandwidth 64

ip address XXXX....

ip nat inside

encapsulation frame-relay IETF

frame-relay interface-dlci 130

service-policy output VPN-POLICY

two things i can not understand

1.why ip dscp value is used can not we priortise traffic on bandwith. whats the advantage of using ip dscp.

and

2. if the link BW is 64 k then how we can shape average to 256 k

Please explain.

Thanks

Saurabh

QOS question Shape peak and Shape average

Peter Paluch — Wed, 14 Dec 2011 07:44:55 GMT

Hi Joseph,

I've performed the experiments in our network lab using 1841 routers running 15.1(4)M2 Advanced IP Services, interconnected via Fa0/1 interfaces. The topology:

Generator ---> (Fa0/0) 1841 (Fa0/1) ---> (Fa0/1) 1841 (Fa0/0) ---> Receiver

The shaping was configured on the leftmost 1841 as follows:

policy-map fa0/1-out

class class-default

no fair-queue

shape average 100000 8000 8000

interface FastEthernet0/1

service-policy output fa0/1-out

The generator created a flow of IP/UDP packets of total size of 1000 bytes, 150 packets per second, totalling a rate of 1.2 Mbps.

I used Wireshark to capture the flow and graph it out. Following is the screenshot of the graph flow:

Up to the roughly 180th second, the configuration of the shaping was as indicated, i.e. shape average 100k 8000 8000. The graph shows the throughput to oscillate around the configured CIR of 100 Kbps. At around the 180th second, I have modified the command to

shape peak 100000 8000 8000

As it can be seen, the total throughput jumped twofold and now oscillates around the value of 200 Kbps which appears to align with my original explanation and derivation of CIR' = configured CIR * (1+Be/Bc) = configured CIR * 2, as in my case, the Be=Bc.

Furthermore, around the 230th second, I modified the configuration again to:

shape peak 100000 8000 4000

The rate dropped to 150 Kbps which also aligns to the CIR' = configured CIR * (1+4000/8000) = configured CIR * 1.5

This experiment used the generator to create a substantially higher load than the configured CIR. Another experiment was performed under the same sequence of settings on the router, however, the stream consisted of 100 byte packets, 300 packets per second, totalling the rate of 240 Kbps.

In short, the results were absolutely identical, see the following graph:

Till the 95th second, the shape average 100k 8000 8000 command was used. Between the 95th and 130th second, the shape peak 100k 8000 8000 was used. After the 130th second, the shape peak 100k 8000 4000 was used.

If these experiments do not align with what you requested, Joseph, please feel welcome to give me your description of the experiment so that I can replicate it in our lab.

My personal feeling is that the shape peak is good for those customers who have negotiated both the CIR and EIR with their service provider (Bc, Be and Tc), and want to always shape up to CIR+EIR, i.e. they want to always go to the PIR, accepting the risk that the packets over the CIR may get dropped or marked for future dropping. Naturally, they specify the CIR in their shape peak command but the shaping in this case is backed up by the idea that they can always send Bc+Be bytes.

I would love to hear your opinion on all of this.

Best regards,

Peter

QOS question Shape peak and Shape average

Joseph W. Doherty — Wed, 14 Dec 2011 10:57:34 GMT

Disclaimer

Liability Disclaimer

Posting

"If these experiments do not align with what you requested, Joseph, please feel welcome to give me your description of the experiment so that I can replicate it in our lab."

Peter, your experiments do align with what I requested, and thank you very, very much for taking the time and effort to conduct them!

"I would love to hear your opinion on all of this."

First, your experiment not only confirms your explanation of what you expected but also confirms an experiment I had a hazy recollection of trying myself years ago, as I've already noted. Yet, if you re-read my original post's Cisco text, these results are, I believe, contrary to what one would expect if only Bc tokens are replenished per Tc.

Further, I'm not sure I see the benefit of such an implementation because as you've already noted, you can achieve the same results by using average 2x vs. peak 1x (or other settings of average, i.e. your shape peak 100000 8000 4000 test could be 1.5x average, i.e. shape average 150000 8000 8000).

If peak actually worked as I believe it should (also more like ATM's PCR/SCR), it would maintain a long term (average) CIR yet support transient bursts better. Consider my prior posting (assuming average and peak functioned as described) where the transient bursts would have less latency (if shaped) or less drops (if policed).

To reiterate, if shape average 200000 8000 # equals shape peak 100000 8000 8000 or shape average 150000 8000 # equals shape peak 100000 8000 4000, I'm not seeing a real advantage of having both average and peak; do you?

Again, Peter, thank you so much for your effort in investigating this.

Re: QOS question Shape peak and Shape average

Joseph W. Doherty — Wed, 14 Dec 2011 11:16:46 GMT

Disclaimer

Liability Disclaimer

Posting

I did not understand from here

Shape peak will xmit 300 Mbps and decrement 50 Mbps from Be (leaving 200 Mbps credit).

From Peter's experiment, peak shaping does not appear to function as I expected, so unsure you would benefit from my explaining, but if you still want me to, please let me know.

1.why ip dscp value is used can not we priortise traffic on bandwith. whats the advantage of using ip dscp.

and

2. if the link BW is 64 k then how we can shape average to 256 k

#1 you don't need to use DSCP tags. What they are really for is to allow later/downstream devices to classify the traffic faster.

For example, later devices, instead of:

class-map match-all Trading

match access-group name QoS-Trading

could

class-map match-all Trading

match ip dscp af42

(NB: if you have an MPLS connection, your MPLS provider might also examine and utilize DSCP markings.)

#2 you can not. Shaping is often used for the reverse, where you have more physical bandwidth then you have logically. For example, today some WAN connection might be provided by Ethernet but you haven't contracted for all the bandwidth. Say you had a 10 Mbps Ethernet connection but you've only contracted for 5 Mbps, a shaper could be used to restrict your usage to the 5 Mbps. This becomes important since QoS queuing only engages where there's congestion. If you sent 6 Mbps across a 10 Mbps Ethernet without a shaper, a policy like your child policy would not engage (additionally what will the your service provider do with your excess 1 Mbps?). If you shape in your parent for 5 Mbps, then the traffic would be prioritized and/or dropped as you desire.

PS:

If you only have 64 Kbps, no need to shape, just use your "child" policy as you main policy on the interface.

BTW, I normally recommend against using WRED unless you really, really understand the technology.

NB: if your interface only has 64 Kbps it shouldn't accept your policy with hard coded bandwidth that exceed interface bandwidth, you'll need to adjust to fit, or if the IOS is new enough, you can use percentage based bandwidths.

PPS:

BTW, when working with cloud WAN techologies, besides ingress into the cloud you often need to consider cloud egress. If you're using MPLS, most vendors can provide some QoS policy support. You'll need to work with them for that.

Re: QOS question Shape peak and Shape average

Peter Paluch — Fri, 16 Dec 2011 09:57:47 GMT

Hi Joseph,

To reiterate, if shape average 200000 8000 # equals shape peak 100000  8000 8000 or shape average 150000 8000 # equals shape peak 100000 8000  4000, I'm not seeing a real advantage of having both average and peak; do you?

I do not, either. Sustained rate of the one can be recalculated into the sustained rate of another. The size of the bursts may apparently differ, though: with constant load, the shape average can burst up to Bc bytes, whereas shape peak always bursts up to Bc+Be, but you could recalculate both values so that the bursting is identical again... phew. This seems to be a rather useless feature in the IOS, only contributing to users' confusion.

Petr Lapukhov tried to explan it in his own words here:

http://blog.ine.com/2008/08/26/understanding-the-shape-peak-command/

But even he admits that with proper argument manipulation, one command can be forced to behave exactly as the other.

Best regards,

Peter

Re: QOS question Shape peak and Shape average

Joseph W. Doherty — Fri, 16 Dec 2011 11:56:32 GMT

Disclaimer

Liability Disclaimer

Posting

Hmm, personally I don't think its especially accurate to consider either shape average or shape peak to "burst" when both allow you to sustain their rate. This is like saying Ethernet allows you to burst to 10 Mbps (it does, but also allows that as a sustained rate) although I've seem such references too.

It's interesting your referenced blog mentions frame-relay and minCIR, since I had thought to mention them where I mentioned ATM's PCR/SCR, but I thought the latter a better representation of burst allowance over a committed rate as it's enforced by the interface without any dependence on some kind of actual congestion indication.

I didn't read the blog throughly, but don't believe I noticed any reference to token replenishment. This is what could make all the difference. Your tests seem to demonstrate that replenishment doesn't operate as documented in the Cisco reference I provided, for if it did, don't believe you would have obtained the results you did.

Well put "This seems to be a rather useless feature in the IOS, only contributing to users' confusion." but I think it would be useful if it operated as I think it should, i.e. peak allowing carrying forward some credit for prior bandwidth utilization below CIR.

Peter thanks again for your effort and analysis. I hope the original poster didn't mind this side bar.

QOS question Shape peak and Shape average

svaishya20 — Tue, 20 Dec 2011 11:51:48 GMT

Hi Joseph and Peter,

Sorry , i was away from the discussion.

and i did not mine for the sidebar its making my funda more clear. thanks peter for doing lab test.

I would like to ask few question from my previous config.

policy-map VPN-CHILD-POLICY

class Trading

set ip dscp af31

bandwidth 200

class Netman

set ip dscp af42

bandwidth 16

class class-default

set ip dscp af21

bandwidth 40

random-detect dscp-based

policy-map VPN-POLICY

class class-default

shape average 256000

service-policy VPN-CHILD-POLICY

1.Total bandwith assign to different classes should not be max then 64k which interface bandwidth.

or can we assign more BW to differnet classes - i do not think so because interface BW is 64k.

like here class trading

200

Netman

and default

so total is 256.

so this total bandwith should be equal to 64K or less than 64k.

PS:

If you only have 64 Kbps, no need to shape, just use your "child" policy as you main policy on the interface.

what will be the result if i use shape average ? and second thing if i am using shape average then what value of CIR i should assign for 64k.

Can we assign shape average to the interface bandwidth.

ex-

it will be shape average 64000 ? or should be less than 64000

and below config is right ?

policy-map VPN-CHILD-POLICY

class Trading

set ip dscp af31

bandwidth 200 -> should be less than 64k

class Netman

set ip dscp af42

bandwidth 16

class class-default

shape average 64000 Bc ? Be ?

How do we calculate CIR on interface bandwidth or we can assign any value less than actual BW.

Please explain.

Thanks
Saurabh

QOS question Shape peak and Shape average

Joseph W. Doherty — Tue, 20 Dec 2011 16:03:14 GMT

Disclaimer

Liability Disclaimer

Posting

I'm a little confused. What's the interface's actual bandwidth?

You normally only need to shape if you there's a need to hold traffic below available physical bandwidth. Shaping (or policing) can be used to "reserve" bandwidth for other traffic, but prioritization (if supported) is often better.

For example, say your link had both VoIP flows and bulk high bandwidth consuming flows. You could shape or police the bulk traffic to leave what you believe would be sufficient bandwidth for the VoIP traffic, but then bandwidth not being used by VoIP would go unused. Instead if you prioritize the VoIP traffic, it gets the bandwidth it needs when it needs it, but your bulk traffic could fully utilize the link otherwise unused bandwidth.

From what you've have seen to have described, you have no need to shape bandwidth for 256 Kbps if your physical bandwidth is 64 Kbps (because the shaper would never engage). If you had 256 Kbps there can be reasons why you might need to shape for 64 Kbps, but they don't appear to apply in your case.

QOS question Shape peak and Shape average

svaishya20 — Wed, 21 Dec 2011 06:29:22 GMT

Hi Joseph,

thanks for replying.

bandwidth for interface is 64k.

but if you will have a look on policy they configured the 200 for

policy-map VPN-CHILD-POLICY

class Trading

set ip dscp af31

bandwidth 200

that means you are allowing 200k that is not possible if your bandwidth is hardcoded to 64k.

so i need to adjust bW less than 64k what bandwidth i want to shape it.

and second thing shape average we need to configure always under class default.

and if we configure shape avergae 64000 - to the actual bandwith of interface the it will engage qos or not.

if we put command shape average 64000 do we need to also put value for Bc and Be or we can just leave shape average 64000.

if we need to put Bc and be value then how do we calculate.

Sorry, i am asking you to many question but i think you expalnation will make my funda more clear

Thanks

Saurabh