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
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
"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
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
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 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