Traffic Shape or Rate Limit

Christopher J. Wolff chris at bblabs.com
Tue Oct 2 21:56:36 UTC 2001


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 at bblabs.com
phone:520.622.4338 x234


-----Original Message-----
From: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu]On Behalf Of
Alex Bligh
Sent: Tuesday, October 02, 2001 1:27 PM
To: Christopher J. Wolff; nanog at 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





More information about the NANOG mailing list