Hello, 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. Regards, Christopher J. Wolff, VP, CIO Broadband Laboratories, Inc. http://www.bblabs.com email:chris@bblabs.com phone:520.622.4338 x234
Everything drops packets if you fill the buffers... Rate limiting vs Traffic Shaping is about intent and QoS in my experience. YMMV Deepak Jain AiNET -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Christopher J. Wolff Sent: Tuesday, October 02, 2001 12:36 PM To: nanog@merit.edu Subject: Traffic Shape or Rate Limit Hello, 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. Regards, Christopher J. Wolff, VP, CIO Broadband Laboratories, Inc. http://www.bblabs.com email:chris@bblabs.com phone:520.622.4338 x234
On Tue, Oct 02, 2001 at 12:51:39PM -0400, Deepak Jain wrote:
Everything drops packets if you fill the buffers...
Rate limiting vs Traffic Shaping is about intent and QoS in my experience.
There are some devices that attempt to control traffic without filling buffers, such as the PacketShaper range of products by Packeteer. The PacketShapers control performance of individual TCP sessions by modifying the window size advertisements in flight to simulate reactions to congestion conditions. I have used PacketShapers before. They can be very capable and useful boxes if matched to appropriate traffic/flow volumes (and if the applications responsible for the traffic being shaped are tolerant of the layering violations that the boxes engage in). Joe
"Christopher J. Wolff" wrote:
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.
Traffic shaping may drop less packets, but it can't not drop packets if offered load eventually fills the buffers. The choice of which to use is probably a trade-off and the benefits of each depend on the implementation. If you're looking for simple, strict rate-limiting may be the way to go. The customer (or even you) might try AQM mechanisms to help deal with congestion if that is a big concern. Traffic shaping may give the customer some breathing room at the expense of some latency during short periods of congestion. You could get real cute with traffic shaping by applying policies to different types of traffic, but this is probably something the customer would want control over. My preference would be to be to setup strict rate limits so it looks like a simple single speed pipe. John
Date: Tue, 02 Oct 2001 13:43:28 -0500 From: John Kristoff <jtk@depaul.edu>
[ snip ]
My preference would be to be to setup strict rate limits so it looks like a simple single speed pipe.
Consider also RED variants versus simple tail-drop. Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
"E.B. Dreger" wrote:
My preference would be to be to setup strict rate limits so it looks like a simple single speed pipe.
Consider also RED variants versus simple tail-drop.
Yes, if you know me that goes without saying, however I know a number of a number of folks, particularly at large ISPs that are opposed to RED for one technical reason or another. John
Date: Tue, 02 Oct 2001 14:37:59 -0500 From: John Kristoff <jtk@depaul.edu>
Consider also RED variants versus simple tail-drop.
Yes, if you know me that goes without saying, however I know a
(That I do not... still pretty new on NANOG.)
number of a number of folks, particularly at large ISPs that are opposed to RED for one technical reason or another.
I've seen papers/posts for, against, and neutral on, various RED flavors. Rather than start a flame war or dig up bookmarks, I decided to bring up the subject and effectively say "STFW". :-) One probably should mention, too, that there are various queueing disciplines besides the [seemingly] most ubiquitous RED. Any others would probably require consideration of hardware used. Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
Although very similar, both shaping and limiting are designed to do separate functions, and could in fact operate together. Generally speaking, shaping uses a queuing mechanism to "delay" flows that do not meet predefined bandwidth parameters. Shaping attempts to keep your average throughput the same, giving you a more predictable flow. Rate limiting is a little more rudimentary with respect to policing traffic flows. When packets exceed bandwidth thresdholds defined, the router makes a decision to 1) lower the priority of packets that have exceeded the threshold, or 2) discard the packet. You can actually utilize both technologies in your network. Policing could be done inbound or outbound and shaping could be done on outbound interfaces. Shaping is usually a little more forgiving with respect to bursy traffic flows, however, queueing is introduced that may introduce additional delays. So, I think the answer is, it depends. It depends on where you are in the network, edge vs. core, and giving up processing/delay vs. overall throughput. My 2 cents worth, Brad -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Christopher J. Wolff Sent: Tuesday, October 02, 2001 11:36 AM To: nanog@merit.edu Subject: Traffic Shape or Rate Limit Hello, 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. Regards, Christopher J. Wolff, VP, CIO Broadband Laboratories, Inc. http://www.bblabs.com email:chris@bblabs.com phone:520.622.4338 x234
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
Alex Bligh was alleged to have written:
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.
If your trying to test with a-typical real-world parameters, wouldn't it be prefereable to also test utilizing a clear channel pipe with a rate-limited/policed PVC defined? My experience has been that most carriers don't like to deliver channelized DS-3's, instead they throw out a clear-channel loop, aggregate it into their ATM network, drag it to their router etc, then define an ATM PVC across it to the rate agreed upon to do the "fractionalizing". (I suspect this has something to do with the fact that Channelized cards for their switches tend to be bit more expensive and less cost effective for Frac DS-3 usage?) In the ATM-based Frac DS-3 scenario, you're doing rate-limiting by default as you must define the PVC to the bandwidth that you are selling to your customer. (typically at your ATM switch with matching rate queues on your router as well). Perhaps shaping would come in handy however to optimize/prioritize particular types of traffic for your customer(s). All in all, IMHO, I think you really have to consider how you are aggregating your customers to your network, and how policing or shaping will play into/against that. If you're aggregating via an ATM switch into your router(s), it becomes a different ball game from terminating individual clear channel or even channelized pipes directly to your router(s). I do agree though, if it agrees with your network/aggregation design, shaping is much nicer. /Alex Kiwerski
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
participants (8)
-
Alex Bligh -
Alexander Kiwerski -
Brad Bonin -
Christopher J. Wolff -
Deepak Jain -
E.B. Dreger -
Joe Abley -
John Kristoff