From: Menga, Justin (Justin.Menga@xxxxxxxxxx)
Date: Fri Nov 09 2001 - 00:31:43 GMT-3
Relating to burst only, since it's easy to understand:
The burst size defines the maximum number of bytes that can be sent in a
'burst' over the measurement interval. A burst occurs when the access rate
of the line is higher than the desired rate. The measurement interval (T)
is basically the burst (in bits) divided by the configured rate. Say if you
have the rate at 32000bps and the burst at 96000 bits (12000 bytes) - T
would be 3 seconds. Say an application is sending at 96000 bits per second
- because the burst is 96000, the first second of traffic is permitted.
However, over the next 2 seconds traffic is dropped as the burst has already
been reached. Once a new T period begins, the application is then permitted
to send 96000 bits again (over a 3 second period).
Now excess burst:
Excess burst allows for data streams to 'borrow' bandwidth - the policer
basically keeps track of how much bandwidth has been borrowed (debt), and
compounds the debt over time (and still sends traffic) until the compounded
debt would exceed the excess burst size. Once this happens, traffic starts
to be dropped, and the compounded debt is wiped to zero (the policer also
tracks actual debt, which is not wiped to zero). Again, traffic can exceed
the rate, however it incurs debt and the compound debt grows again until
another drop occurs. If an application constantly exceeds the rate,
eventually the actual debt is so high (exceeds the excess burst), and then
the actual debt is wiped by dropping ALL traffic until the actual debt is
zero.
Basically, excess burst allows for bursty applications to burst higher than
the standard burst limits for a short period of time without drops. Once
the burst is over, debt is reduced if the rate falls below the configured
rate. This allows for bursts in the future. If an application always sends
at the excess bit rate, the max rate over time will never be higher than the
configured rate due to the requirement to remove debt. Thus excess burst
only allows for short bursts and prevents drops of those short bursts.
So when you are selling or configuring CAR for the customer, they need to
understand that they will only ever get the average rate for say a download
of a large FTP file. However, if they are using HTTP to surf the web, the
response will be better than if they had no excess, because he bursts of
traffic will be permitted due to the idle times between bursts. It is wrong
to sell the excess rate as being the maximum bandwidth they will receive -
the customer will perceive this in terms of things like an FTP download,
etc. The excess rate is the max bandwidth they will receive for a short
time (and avoids burst drops) only - they can only use that excess rate
again once their has been some idle or reduced rate time.
Regards
Justin Menga CCIE#6640 CCDP CCNP+Voice+ATM MCSE+I CCSE
Network Solutions Architect
Wireless & E-Infrastructure
Compaq Computer New Zealand
DDI: +64-9-918-9381 Mobile: +64-21-349-599
mailto: justin.menga@compaq.com
web: http://www.compaq.co.nz
-----Original Message-----
From: Mark Lewis [mailto:markl11@hotmail.com]
Sent: Friday, 9 November 2001 2:40 p.m.
To: ccielab@groupstudy.com
Subject: OT QoS: CAR sanity check !!!
Guys,
I need a quick sanity check on a CAR config. Any help is much appreciated.
(1) I need to configure CAR such that each customer (as specified by a
seperate ACL) has an average rate being 32000 bps, and the peak rate being
128000 bps. Here's my config
interface serial x/y
rate-limit output access-group 101 32000 96000 96000 conform-action
transmit exceed-action drop
rate-limit output access-group 102 32000 96000 96000 conform-action
transmit exceed-action drop
.
access-list 101 permit ip any 10.1.1.0 0.0.0.255 !customer A access-list
102 permit ip any 10.2.2.0 0.0.0.255 !customer B
(This is a multipoint DS-3 i/f, and will have multiple rate-limit statement
(maybe 30+). Anybody know of a limit on rate-limit statements per i/f ?).
As I understand it, the above config will allow an average rate of 32k, and
then above 32000+96000 (normal AND excess burst) = 128k, all traffic will be
dropped.
Of course, normally only SOME (random) traffic is dropped above normal
burst, BUT because excess burst is equal to normal burst, ALL traffic will
be dropped - am I right ?
(2) There's a secondary issue here - the traffic being transmitted is TCP,
and therefore the above will cause TCP slow start (ie. there will be tail
drops). This will I suppose only occur when the aggregate traffic rises
above 128k (per rate-limit). Anybody got any thoughts on this ?
Thanks very much in advance,
Mark
This archive was generated by hypermail 2.1.4 : Fri Jun 21 2002 - 06:45:10 GMT-3