[c-nsp] Customer Facing Interfaces: Policing vs. Shaping
andy at xecu.net
Tue Oct 19 12:14:40 EDT 2004
On Tue, 19 Oct 2004, Vincent De Keyzer wrote:
> If I want to deliver 1 Mbps to a customer who has an E1, I usually use
> "traffic-shape rate" because "rate-limit output" causes packet losses and
> gives terrible performance - I would be at 600kbps or something on a FTP
> transfer (1000 kbps during one 5-second interval, and 400 kbps during the
> next - I can send you STG screenshots if you want). Now, the impact on
> several streams rather than one may be less terrible.
> But shaping the incoming traffic is not possible afaik - I usually shape
> output traffic on some other interface that matches the upstream traffic of
> the customer (with ACLs and "traffic-shape group") if necessary.
I use rate-limit statements (CAR) without issue.
NB: Because CAR doesn't increase RTT as the % of utilization increases,
TCP doesn't back off, and thus packets won't make it eventually (being
policed), you will do a new slow start, and your TCP session will be
forced into a sawtooth.
HOWEVER, if you properly set the burst sizes (which seem VERY excessive at
first), you will discover that the TCP sessions is allowed to burst above
the configured rate-limit just long enough to counteract the affects of
the slow start.
So, low-volume TCP transfers aren't really affected, only high-volume
(file transfers). And my testing shows that even with the saw-tooth
affect, the configured throughput is achieved perfectly.
Let's say you're limited at 1 meg. If you download a file >1meg (while the
rest of the pipe is unused), your transfer rate will result in 1mbps, even
with the repeated slowstarts. If your pipe is used, you will find the
aggregate transfer rate to be (1meg - currentusage).
Works great for us, our customers would be kicking in our doors othewise.
This is the proper way to configure CAR:
rate-limit <direction> X 1.5X/8 3X/8
where X=desired bandwidth in bits per second.
More information about the cisco-nsp