QOS question Shape peak and Shape average

[svaishya20]

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

[Peter Paluch · Accepted solution]

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

[svaishya20]

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

[Peter Paluch · Accepted solution]

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

[svaishya20]

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

[Joseph W. Doherty]

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.

[jmcgrady1]

Sorry i am having trouble understanding the various terms. If i have a connection which is 1000mb/s ethernet, and my provider is policing it to 100mb/s, what would my shaping command look like to best utilise that 100mb/s?

I ask because my current "shape average 95000000" config is seeing drops for the class-default class. 

I would not normally consider CIR, Bc, and Be because i treat this as 100mb/s available with no burst ability.

[Joseph W. Doherty]

In theory, the controlling/parent shaper should be set to match available bandwidth.  However, I believe, some Cisco devices' shapers do not account for L2 overhead.  If they don't you can shape for what would be the effective bandwidth discounting L2 overhead.  Unfortunately, L2 overhead varies per packet size,  In practice, I've found using a discount of about 15% usually works well.  I.e. for 100 Mbps, shape for (about) 85 Mbps.

As to your issue concerning drops, I have seen your other post, and likely will respond to it later today.

[Joseph W. Doherty]

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

[Peter Paluch]

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

[Joseph W. Doherty]

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

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

[Peter Paluch]

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

[Joseph W. Doherty]

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

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

[svaishya20]

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

[Joseph W. Doherty]

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

 
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.