[nsp] Rate - limiting

[Dan Armstrong]

Did you let the router figure out those second and third values, or did 
you calculate them?

We have never been able to make policing work well... using your 
numbers, I was able to get _closer_ to 500K (about 364) using a single 
ftp stream as a test.  Using the default second and third number, I get 
about 25Kb/s

If I use shaping, I get almost exactly 500Kb/s....

Dan.




Bruce Robertson wrote:

>>Rate limiting at lower speeds severelt impacts TCP performance, a single 
>>TCP session hitting a rate limit will start, hit the ratelimit, lose 
>>several packets, pretty much go into slow-start, go logarithmically up 
>>again to the rate limit, hit the hard ceiling and then go into slow-start 
>>again, cutting the used bandwidth to approx 40% of the ratelimit.
>>    
>>
>
>This behavior is avoided if you use random-detect along with rate limiting.
>Here's an example that works perfectly at limiting a user to 500 Kb/s:
>
>
>interface FastEthernet0/0
> no ip address
> random-detect 
>
>interface FastEthernet0/0.22
> encapsulation isl 22
> ip address x.x.x.x y.y.y.y
> ip verify unicast reverse-path
> no ip redirects
> no ip proxy-arp
> rate-limit input 496000 93750 187500 conform-action transmit exceed-action drop
> rate-limit output 496000 93750 187500 conform-action transmit exceed-action drop
>
>
>--
>Bruce Robertson, President/CEO				     +1-775-348-7299
>Great Basin Internet Services, Inc.			fax: +1-775-348-9412
>http://www.greatbasin.net
>
>
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/
>  
>