[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