[nsp] rate-limiting

Andrew Fort afort at choqolat.org
Wed Oct 8 19:47:12 EDT 2003


Raymond, Steven said the following on 9/10/2003 8:30 AM:

>>Hi Christopher,
>>
>>I know that when using traditional CAR, your policer 
>>bucketsize values 
>>are incorrect.  I assume the policer is implemented similarly 
>>with the 
>>modular QoS on the same platforms.
> 
> 
> Can anyone point to a CCO link that usefully describes the meaning and use
> of the bucketsize parameters?  In my trial & error testing with a smartbits,
> I found that the closest approximation to limit a FE circuit to say, 50Mb/s,
> would be something like this:

http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800bd8ed.html#1001055

"
Testing of TCP traffic suggests that the chosen normal and extended 
burst values should be on the order of several seconds worth of traffic 
at the configured average rate. That is, if the average rate is 10 Mbps, 
then a normal burst size of 10 to 20 Mbps and an Excess Burst size of 20 
to 40 Mbps would be appropriate.

Recommended Burst Values
Cisco recommends the following values for the normal and extended burst 
parameters:

normal burst = configured rate * (1 byte)/(8 bits) * 1.5 seconds
extended burst = 2 * normal burst

With the listed choices for parameters, extensive test results have 
shown CAR to achieve the configured rate. If the burst values are too 
low, then the achieved rate is often much lower than the configured rate.
"

The values above, in my experience, work reasonably well for a mix of 
TCP/UDP flows (i.e., in an SP environment).

> Furthermore, is there a difference in the configuration when doing straight
> interface rate limiting (CAR?) vs the modular QOS style?

The configurations are quite different, but on the same platform the 
policer seems to work similarly enough.

-afort




More information about the cisco-nsp mailing list