RE: rate-limit vs. police

From: Chris Lewis (chrlewiscsco@yahoo.com)
Date: Sat Oct 08 2005 - 16:51:32 GMT-3


Good explanation Simon. However, there is no Tc in policing as there is in shaping. Tc in shaping defines the interval at which tokens are replenished in the bucket. In policing tokens are replenished at the rate of (T-T1)CIR, where T is the curent time and T1 is the time of last packet arrival.
 
In shaping Bc defines the bits transmitted per interval to reach CIR, and therefore does not really specify any burst at all. In policing Bc does specify a burst, as you define below.
 
This detail I think though is largely irrelevant for practical applications, however I can imagine a question on the lab that could say use a rate limiting mechanism that replemishes tokens at regular intervals (calling for shaping), or one that calls for a rate limiting mechanism that replaces tokens based off packet arrival time (calling for policing). This is my only reason for mentioning it here.
 
 
 
Chris

simon hart <simon@harttel.com> wrote:
Hi

They use different policing algorithms.

CAR first

The CAR method uses only one token bucket, it also uses actual and compound
debt to decide when traffic is in our out of contract. The following link
in the Doc CD describes the CAR algorithm:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos
_c/fqcprt4/qcfpolsh.htm#wp1000920

Lets explore the following command

rate-limit output 1000000 187500 375000 conform-action transmit
exceed-action drop

This statement will limit the average throughput to 1Mbps. The Token Bucket
is 187500 bytes (bc) which can extend burst (be) to 375000 bytes - it is
important to remember that we are defining just one bucket here, therefore
the figures are accumulative - different from MQC Police!!.
By doing the maths on this one can work out that the Time interval is 1.5
second as per Cisco recommendation for CAR ( 187500*8)/1000000 = 1.5. Also
the Cisco recomendation is that the extended burst be twice the standard
burst.

Packets that conform will be transmitted, and those that do not will be
dropped.

The Actual Debt and Compound Debt algorithm explained in the above link
describes the behaviour of the policer once packets are exhausted from the
Token bucket. The values of bc and be are used to regulate this action.
Effectively the CAR policer does not aggressively police non conforming
packets but behaves in a RED like fashion until a point when all
non-conforming packets are dropped.

Police within MQC

The police command within MQC is based upon an IETF algorithm - Single Rate
Three Colour Marker - rfc 2697

This policer has two token buckets, one is defined by Bc and the other by
Be, therefore the figures for Bc and Be do not have to be accumulative.

police 1000000 31250 1000 conform-action transmit exceed-action set-dscp
16 violate-action drop

With this command we are againg shaping at a throughput of 1000000. The
first token bucket is define as 31250 bytes, again by doing the math you
will notice that the Tc is now 250ms. In fact if you just put the command
police 1000000 this is what the IOS will default too. The exceed bucket is
defined as 1000 bytes.

Using the statement above the algorithm works in this fashion

Time interval = 250ms

Time interval 1 - Bytes offered 20000 Bc full therefore transmit 2000
bytes

Time interval 2 - Bytes offered 32250 Bc full therefore transmit the first
31250 bytes (remember Bc = 31250). Be full transmit the remaining 1000 bytes
and take exceed action - set dscp 16.

Time interval 3 - Bytes offered 32250. Bc full therefore transmit the first
31250 bytes. Be exhausted in last time interval, therefore take violate
action - drop on remaining bytes

Time interval 4 - No Bytes offered. Bc full. Be still exhausted

Time interval 5 - No Bytes offered. Bc full and overfilling!! Refresh Be
with 1000 bytes

Time interval 6 - 40000 Bytes offered. Bc full therefore transmit the first
31250 bytes. Be full transmit following 1000 bytes with exceed action of
set dscp 16. Remaining 81250 bytes take violate action - drop

There are also some other differences that you need to cogniscent of!! The
IOS allows you to set the Be in the following command

police 1000000 31250 1000 conform-action transmit exceed-action drop

In this situation there really is no burst capability. As you can see
anything offered in excess of 31250 bytes per interval is going to get
dropped. Therefore the Be makes little sense. In fact if you do a show
policy interface, you will see that the Be does not appear. Also in this
way the policer is far more aggressive than CAR!!
This command can be confusing as well

police 1000000 31250 1000 conform-action transmit exceed-action set-dscp 16

Again, the sames as above, any packets above 31250 in any interval will have
the set-dscp 16 applied, not just the Be of 1000!! Therefore if you want
the algorithm to work as a 2 bucket policer you have to add the
violate-action command.

When to use the one of the other will vary much depend on the wording of the
question I am afraid, but if you understand the subtle differences you
should be able to pick the most appropriate command.

Now that is explained, I let you try and work out:

police cir 1000000 bc 31250 pir 2000000
conform-action transmit
exceed-action set-dscp-transmit af11
violate-action drop

Hope that Helps

Simon

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
dusth@comcast.net
Sent: 08 October 2005 17:58
To: ccielab@groupstudy.com
Subject: rate-limit vs. police

Hi group,
Can some one with good knowledge about the differences b/t these two method
and shed me some light? I'm confused when to use rate-limit and when to use
police. Basically, I read the cco docs look like they all both offer same
functions to me
Thanks, Dustin



This archive was generated by hypermail 2.1.4 : Sun Nov 06 2005 - 22:00:49 GMT-3