Sorry for the confusion. By Traffic Shape or Rate-Limit I was referring to Cisco's implementation of the Traffic-Shape vs Committed Access Rate respectively. I understand that CAR is more of a brutal method of traffic control; just wanted to know what the implementation was like by Nanog members on a real-world, high cap DIA basis. My personal opinion is that I would rather run Traffic-Shape because its a pain in the butt for my feeble old brain to work through inverse netmasks! HAHA Regards, Christopher J. Wolff, VP, CIO Broadband Laboratories, Inc. http://www.bblabs.com email:chris@bblabs.com phone:520.622.4338 x234 -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Alex Bligh Sent: Tuesday, October 02, 2001 1:27 PM To: Christopher J. Wolff; nanog@merit.edu Cc: Alex Bligh Subject: Re: Traffic Shape or Rate Limit Christopher,
I'm wondering what the list's opinions are on Traffic-Shaping vs. Rate-Limit for DIA customers (Frac DS3, for example). From what I've read, Traffic Shaping is a better option since it doesn't drop packets. Just curious as to what the opinions are.
Terminological nit: I have seen rate-limiting used to refer to many mechanisms of traffic control. I think what you are talking about as an alternative to shaping, is just policing, i.e. dropping excess packets, based on some token-leaky bucket algorithm (as opposed to packet-leaky bucket) algorithm. An example of policing is Cisco's implementation of CAR (committed access rate) which uses a dual leaky bucket token algorithm - when the bucket is empty of tokens, packets get dropped on the floor 'immediately'. The difference between shaping and policing is mainly the introduction of a queue. This delays packets (i.e. adds latency). However, note that the queue is of finite length, and eventually shaping will drop packets. If you are are trying to simulate a circuit of lower bandwidth, then use shaping. If you use policing (only) you will see packet drops far too early. These really break the TCP algorithm, whose window sizing algorithms expect to see increasing delay (as output queues fill), prior to be being hit with packet loss. You also tend to see gross unfairness in what packets are dropped. Plotting window sizes, throughput, etc. (anything) in a lab environment will quickly demonstrate that shaping is the way to go. [Note that policing has its applications, so for instance if your customer runs their own CPE, they may have to shape on output towards you, as opposed to you shape on input - you may want to police to ensure they have done what they committed to do. Also policing is good for stuff like removing DoS]. The problem with shaping is it is, in general, more consumptive of router resources than policing. CEF/CAR has for a long time been done on the fastest path. It is said that bleeding edge Cisco IOS now does shaping on the fastest path on some boxes, though I don't have the scars to demonstrate the veracity / stability of this. Shaping itself works best when it is configured to look like a serial circuit circuit, which is what TCP/IP was optimized for. Adding burst works well too if it is thought out correctly. But if you don't want burst - you appear to just want to simulate a fractional DS-3 - why don't you just set the relevant number of timeslots to be used either end? This works well. And guarantees no complications. -- Alex Bligh Personal Capacity