Search this Blog

Saturday, December 15, 2012

How to configure burst byte, rate bps and police parameter in cat 3560 QoS

 We are trying to implement QoS on our guest vlan, to limit vlan bandwith to 1Mbps. The cisco config guide about QoS 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. "
How does burst-byte impact rate-bps? How does both burst-byte and rate-bps influence the target to limit bandwidth to 1Mbps?
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.
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.
Citation - This blog post does not reflect original content from the author. Rather it summarizes content that are relevant to the topic from different sources in the web. The sources might include any online discussion boards, forums, websites and others.

No comments :

Post a Comment

/* Google Analytics begin ----------------------------------------------- */ /* Google Analytics end ----------------------------------------------- */