cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
25045
Views
40
Helpful
22
Replies

QOS question Shape peak and Shape average

svaishya20
Level 1
Level 1

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

22 Replies 22

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

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

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

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

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.

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

16

and default

40

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

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

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

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

Ok, if "bandwidth 200" is the issue on a 64 Kbps bandwidth, then correct the allocation or uses a % (if supported).

From what you've described, you don't need to shape.

Review Cisco Networking products for a $25 gift card