BC values Traffic Policing

[JuannNino]

I seem to have conflicting information about the values I should use for the BC value when policing in the following two cisco links

http://www.cisco.com/c/en/us/td/docs/ios/12_2/qos/configuration/guide/fqos_c/qcfpolsh.html#wp1012025

http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-policing/19645-policevsshape.html

one says the value should be  calculated as  CIR * 1.5 times / 8  while the other one shows that BC is less than CIR to make the TC between  10 ms and 125 ms.

if we set up BC to be CIR*1.5/8 and having that TC = BC/CIR then replacing BC we have that TC = 1.5/8 which is 187.5 ms which is outside the recommended range.

so in this case which document is correct?

thanks

[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 wha2tsoever (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

"Correct" depends on what you're trying accomplish, and the various documentation should be thought more along the lines of example usage.

That said, with shapers, you can use a smaller Bc to more closely mimic a transmission rate of a link of the shaper's nominal bandwidth.  This can be especially important when working with delay sensitive traffic, like VoIP.

With policers, setting a smaller Bc is more likely to reduce effective transmission rate below the policer's nominal bandwidth.  So, for those, the CIR*1.5 is generally a better recommendation.

[JuannNino]

thanks, however I understand that when policing or shaping the CIR is the rate you want in average per second, say you want 10Mbps on a gig interface that means you will send 10 Mbits of information on one second. As you are sending it on a gig interface that means that you are able to send 10Mbits in 10ms, then you wait 990ms to send other 10ms of data accomplishing the desired 10Mbps average.

now, the bc helps divide a second in multiple intervals so the spacing between the bursts is low so instead of wating 990ms to send another flow it waits less than that.

say BC=1Mbps(/1s/8bits), you are dividing one second into 10 intervals and sending 1ms of information on each interval.

that is, sending 1ms waiting 99ms, sending 1ms watiing 99ms ... etc. thus accomplishing again an average rate per second of 10Mbps

however if the value for BC is greater (say 20Mbps/1s/8bits) than CIR (10Mbps), you are saying that you could potentially send a burst of 20Mb on one second which is higher than the target rate. so you can assume one of two things. 

1. you are sending twice the rate you actually want to send or

2. the device will ignore the bc and will stick to the value of the CIR, making irrelevant the value of BC when BC > CIR.

in any case. why it should be CIR*1.5 and what it will actually be doing this parameter in the data transferred by the line?

[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 wha2tsoever (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 unsure you correctly understand how a policer operates.  It doesn't send/hold based on the Tc, it clips/drops traffic based on the Tc.  Traffic is always sent at line rate.

For example, your link is physically FE, but you want a "CIR" of 10 Mbps.  Say your link has full rate for the first 100ms and no traffic for the next 900ms.  If Tc is set for 1000ms, all traffic is passed and you've averaged 10 Mbps for 1 second.  But if Tc is set for 100ms, the first 10ms of traffic is passed and the remaining 90ms is dropped.  Now your 1 second average is 1 Mbps!

Again assuming we're dealing with 100 ms burst of traffic on a FE, if you set your Tc to 10ms, the first 1ms would be considered to pass, the next 9ms should be dropped, and this is repeated every 10ms.  But as policers count bits, yet packets are dropped, it's possible 100% of your traffic burst might be dropped!!

So, when dealing with policers, setting CIR to 1.5 times is just a general simplistic recommendation.  What Tc should actually be, depends on CIR vs. actual link speed, packet sizes, expected traffic clustering, and what you're trying to accomplish.

Again, shapers, since they buffer, can generally be used "safely" with much smaller Tcs.  With those, you consider the overhead of the shaper, which generally increases as your Tc decreases, and your service needs, i.e. how closely do you really need to emulate a slower link.

Neither a shaper or policer truly emulate a slower link, again because traffic is still transmitted at line rate.