Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Paolo Bevilacqua wrote:
Joseph, you can shape the interface facing users. That works fine.
If you just want to regulate bandwidth obtainable by downstream devices, yes it (or a policer) does work fine. If you want to fully regulate bandwidth used upstream down to your shaper (or policer), "your mileage might vary". It can be better than nothing, but in my experience, it hasn't worked fine for me. Non-rate adaptive flows don't care and rate adaptive flows can burst over your logical limits (on the upstream side).
Also using a shaper, rather than a policer, might not work as well regulating ingress bandwidth as a policer. This because even for rate-adaptive flows, they might not know to slow until the shaper's queues overflow. I.e. policers usually drop sooner and hence provide feedback to the sending source to slow sooner. (NB: here too your "mileage might might vary" because some of the newest TCP stacks closely monitor RTT, and if they see it jump, they will slow.)
With all the foregoing noted, if your provider has a generous measurement period, and if you're dealing with rate adaptive flows, shaping or policing often do average out close to what they are configured for long term.
This property of short term vs. long term measurements also means you can sometimes set you configuration to drop sooner rather than later, which provides feedback to rate adaptive flows sooner which means they are less likely to burst over your logical cap. (Also again, newer TCP stacks that closely monitor RTT aren't as sensitive to needing drops for flow control. I.e. shaping might work as well for them as a policer.)
In any case, to summarize, it's generally easy to set an outbound shaper (or policer) to avoid busting logical egress caps, but it's not so easy to avoid busting logical ingress caps especially if you actually want to take full advantage of the bandwidth you're paying for. (NB: BTW, this is similar problem to managing ingress upstream bandwidth for specifc QoS purposes, e.g. to guarantee bandwidth for something like VoIP.)
PS:
What can work well with ingress rate-adaptive TCP flows, is using an appliance that regulates (spoofs) both current RWIN and paces outbound ACKs. Unfortunately, the former, as far as I know isn't available as an IOS feature. I've done the latter, but haven't found an IOS offering the granularity needed to do it well.
