cat 3560 QoS, police parameter

[lfgchinadc]

Hello,

     I'm trying to implement QoS on our guest vlan, to limit vlan bandwith to 1Mbps.

     I'm reading the cisco config guide about QoS.

     It says that "Policing uses a token-bucket algorithm."

     There is syntax "

police rate-bps burst-byte [exceed-action {drop | policed-dscp-transmit}] " and It says "

For rate-bps, specify average traffic rate in bits per second (b/s). The range is 8000 to 10000000000. " and "

For burst-byte, specify the normal burst size in bytes. The range is 8000 to 1000000. "

     I don't quite understand how burst-byte impacts rate-bps. How both burst-byte and rate-bps influence my target to limit bandwidth to 1Mbps?

     Could someone give me some hints?

[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

The burst parameter sets the measured time period.  If you want to police at 1 Mbps across 100 ms, you multiply the target rate by the time and divide by 8, i.e. 1,000,000 * .1 / 8 = 12,500 bytes.  10 ms would be 1,250 bytes.

Since policers drop overrate traffic, and traffic is often bursty, you want to lean toward larger periods rather than smaller.  (If you were using a shaper, going smaller brings the actual transmission rate closer to a physical interface of that capacity.)

I recall somewhere there's a recommendation that burst size should not be less that a packet's size, so at 1 Mbps, assuming standard sized Ethernet, you would want a burst size not less than 1500.

If you don't specify the size, the platform will default a value.  Older platforms ususally used a measured period of 25 ms; newer seem to use 4 ms.

[lfgchinadc]

Hello,

     Thanks for the reply.

     But I'm more confused. The minimum burst-bype is 8000 as cisco says.

     and could you check below two police command's difference. what real max speed does the user get?

     1. police 1000000 8000 exceed-action drop

and 2. police 1000000 12000 exceed-action drop

[Joseph W. Doherty · Accepted solution]

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

     But I'm more confused. The minimum burst-bype is 8000 as cisco says.

Sorry for the confusion on the minimum size - got caught up in what Bc represents.

     and could you check below two police command's difference. what real max speed does the user get?
     1. police 1000000 8000 exceed-action drop
and 2. police 1000000 12000 exceed-action drop

Delivered speed depends on the combination of what the traffic is doing and the policer's settings.

Consider you're policing (or shaping) at 1 Mbps on a 10 Mbps Ethernet link.  What's actually happening?  When bits are transmitted, they are always transmitted at actual media speed, in this case 10 Mbps.  So, what a policer (or shaper) does is measure the total transmitted number of bits, over some time period, and drop (or queue) bits (actually packets/frames) that exceed the "rate" for the time period.  However, it doesn't matter when the bits are actually transmitted within the measure time period, but too many bits within a time period matters.

For example, if we counted a "rate" of 1 Mbps on a time period of 1 second, 1 millions bits will actually be transmitted at 10 Mbps for 1/10 of a second.  If the transmission was continuous, the 1/10 of a second could take place anytime within a second, perhaps the 3rd tenth.  Or, if the bits were transmitted continuously for 1/20 of a second, in two instances, the first transmission could take place during the 4th twentieth of a second, and the second transmission any twentieth there after.  Such combinations meet our measured rate, i.e. no more than 1 million bits during a second.

However, suppose we now half our measure period, from 1 second to half a second; i.e. still policing at "1 Mbps".  Now the original transmission of actual 10 Mbps for 1/10 of a second is twice our limit, and if policed, "half" the transmission would be dropped.  If we also again send two transmissions for 1/20 of a second, the first transmission can take place anywhere in the first half second, the second transmission anywhere in the 2nd half second, but if both take place in the same half second, the second transmission would be again, if policed, dropped, although the first transmission would pass.  You can look at the previous 1/10 second transmission as two 1/20 second transmissions back to back.

Where this gets involved, and why actual transmission rate depends on measured time periods and actual traffic, for the second example of measuring across a half second, it would seem to always preclude sending one transmission for 1/10 of a second, yet if that transmission started exactly at the last 1/20 second of the first time period, and runs into the first 1/20 second of the second time period, it would be passed.

So, without knowing exactly both actual traffic transmission characteristics, and your policing parameter, we can't precisely predict what will happen.  What we can say, larger measure time periods (set via the burst size), allow for more "bursty" transmission, but the overall rate will be the same.  However, especially when policing, dropping some packets can change the senders transmission rate, so the impact using different burst sizes can be very noticeable against some traffic (e.g. TCP).

In other words, you second police statement, is likely to allow most typical (i.e. TCP) network traffic to actually near 10 Mbps more so than your first police statement; but can't guarantee that.

PS:

If you think, I'll make the measured time period very large, then remember actual transmission rate is still always at media rate.  If you were enforcing "1 Mbps" on a gig link, and measured time period was 1 minute, this will allow 1 million bits to be send, at gig rate, anytime during the minute.  Is that okay?  That's something you need to determine.

[Florin Barhala]

Hello John,

I read you nice explanation here. You are saying:

"Where this gets involved, and why actual transmission rate depends on measured time periods and actual traffic, for the second example of measuring across a half second, it would seem to always preclude sending one transmission for 1/10 of a second, yet if that transmission started exactly at the last 1/20 second of the first time period, and runs into the first 1/20 second of the second time period, it would be passed."

From the command jimmy niu delivered:

police 1000000 12000 exceed-action drop

Can we find out what would be the actual transmission rate? Is this value the same as Tc?

[lfgchinadc]

Hello,

     Thanks for writing so much.

     I'm not a native English language person so I read your post many times.

     Now I come to understand it.

     Thanks.