From: simon hart (simon@harttel.com)
Date: Sun Oct 09 2005 - 11:38:36 GMT-3
Ryan,
I think you may have the wrong concept of Bc. Bc is committed burst, in
traffic shaping this is the amount of bits that can be sent in one time
interval. With policing if a period of time has passed since sending
packets equivalent to 1000000 / 31250*8 = the number of packets to be sent.
We need to work out how Bc works (before looking at Be and PIR). 31250 * 8
= 250000 bits, if you now divide 250000 / 1000000 = 250ms.
In traffic shaping this means that after each 250ms has passed 250000 bits
can be sent to line. As you can see that in a 1 second period we can send
250000 bits 4 times, which equates to the rate 1000000 bits per second.
There is no excess, no 1250000 in this.
With policing the manner by which the Bc reacts is kind of the inverse of
above, however it achieves similar ends ( the reason it works in a different
way from shaping is that shaping can queue the packets, then 'burst' them
all out at the beginning of a time interval, policing has no queueing so it
will continously 'leak' bits onto line).
For the purposes of this argument (I think Chris maybe able to explain this
more elegantly), if no packets have been sent for a period of longer than
250ms, we can assume that the token bucket can be 'given' a credit of 250000
bits (31250*8). A stream of packets arrive that equate to 250000 bits,
because the bucket is full we can send all the packets to line.
Okay 100ms pass and a stream of packets equivalent to 250,000 bits arrive.
We know look at 100ms and determine how much we can fill our bc bucket. We
know that after 250ms there will be 250,000 tokens in the bucket, therefore
after 1 ms there would be 1000 tokens, thus 100ms would be 100,000 tokens.
From this we can determine that of the 250,000 bits that arrived only
100,000 bits are going to get sent the other 150,000 are dropped.
Now 350ms has passed and we have sent 350,000 bits to line and dropped
150,000 bits. You should be able to see from this that if I extrapolate
further and we have a continous data stream offered, then after 1000ms
1,000,000 bits would get sent to line, no more no less. This is how bc
works in policing, and is very important that you understand it.
Bc is the rate at which we fill the token bucket! Not as you have shown
some additional bits you can send in excess of the configured police rate.
This is where Be comes into play.
When we have Be configured (this is SRTCM and not CAR!! again pretty
important) we have another token bucket, the size of this token bucket is
defined by by Be. So with Be set at 1000, we have a Be token bucket of 8000
bits. This bucket gets filled if and only if the Bc bucket is full to
overflowing.
Here is how it works
Again we have had a quite time on our interface, no packets have arrived
for the last 1 second.
A stream of 300,000 bits arrive. As before we look at our Bc bucket and
determine that we can fill it with 250,000 tokens, thus 250,000 bits can be
sent. However since we have had a quite time, we can overflow some tokens
into the Be bucket, in fact we can allocate 8000 tokens into the Be bucket,
therefore we can send 8,000 bits to line.
So if we have an exceed action of set-prec 0 and violate-action of drop, we
will have done the following
Sent 250,000 bits to line with no modification
sent 8,000 bits to line with prec set to 0
Dropped 32,000 bits
100 ms later another 300,000 bits arrive. As before we can determine that
we can fill our Bc bucket with 100,000 tokens, thus we can send 100,000 bits
to line. However the Bc bucket was not full to overflowing, therefore Be is
empty, we cannot send any excess. So for this time period we have
Sent 100,000 bits with no modification
Dropped 200,000 bits
If this were to continue in a similar fashion we should see that after 1s we
would have sent 1,008,000 bits to line, of which 8,000 bits are modified
with a prec of 0.
So in this instance Bc is the rate at which both the Bc bucket and Be bucket
are filled.
Peak Information Rate
Now in the MQC command we can configure and Committed Information Rate and a
Peak Information Rate. This modifies the behaviour of the Bc and Be
Buckets. They are refreshed independently:
So lets say we have CIR 1,000,000 and PIR 2,000,000 and Bc of 31250 and Be
of 31250. The exceed action is set dscp 16 and the violate action is drop.
At each interval the Bc is checked based upon its rate of replenishment
31250/1,000,000 and the Be is checked based upon its rate of replenishment
31250/1,000,000. As you can see the Be token bucket is not reliant on the
fact that the Bc has 'overfilled', the Be gets replenished independently
(and in this example at the same rate as the Bc)
Safe to say that the overall policed rate will be at 2,000,000 bps of which
over a period of 1 s, 1,000,000 bits will be sent unmarked and 1,000,000
bits will sent with the dscp set to 16.
HTH
Simon
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Private Ryan
Sent: 09 October 2005 14:49
To: simon hart
Cc: Chris Lewis; dusth@comcast.net; ccielab@groupstudy.com
Subject: Re: rate-limit vs. police
from the police statement:
- conform-action transmit ( traffic below 1000000 , conform)
- exceed-action set-prec-transmit 0 ( traffic between 1000000 and
1000000+31250*8 , set precedence to 0 and transmit)
- violate-action drop ( drop if above the 1000000+31250*8)
I have poor concept on be and pir. please correct me if I make mistake.
Thanks !
Ryan
2005/10/9, simon hart <simon@harttel.com>:
> Ryan,
>
> Not sure how you came to 1250000 drops everything. Provide us with your
> math on this and perhaps we can clear things up.
>
> Simon
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Private Ryan
> Sent: 09 October 2005 04:23
> To: simon hart
> Cc: Chris Lewis; dusth@comcast.net; ccielab@groupstudy.com
> Subject: Re: rate-limit vs. police
>
>
> hi
>
> I understand that the situration that police command in following:
>
> police cir 1000000 bc 31250 be 1000
> conform-action transmit
> exceed-action set-prec-transmit 0
> violate-action drop
>
> traffic rate < 1000000bps = allow transmit
> traffic rate > 1000000bps = using token in bc 31250 bytes
> traffic rate > 1250000bps = drop everything.
>
> If I put pir (i.e. police cir 1000000 bc 31250 pir 2000000 be 1000)
> since everything is drop after 1250000bps, what is the use of PIR ?
>
> Thanks !
>
> Ryan
>
>
>
> 2005/10/9, simon hart <simon@harttel.com>:
> > ............and here is the config for a sample two rate three colour
> > marker - enjoy :)
> >
> > police cir 1000000 bc 31250 pir 2000000 be 1000
> > conform-action transmit
> > exceed-action set-dscp-transmit af11
> > violate-action drop
> >
> > Simon
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Chris
> > Lewis
> > Sent: 08 October 2005 20:56
> > To: dusth@comcast.net; ccielab@groupstudy.com
> > Subject: Re: rate-limit vs. police
> >
> >
> > In addition to the other replies, you might consider that with MQC
police
> > you have a two rate three color option, which is not there for CAR, as
> that
> > is a single rate three color marker. This wording could appear in the
> exam.
> >
> > Chris
> >
> > dusth@comcast.net wrote:
> > 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
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > ---------------------------------
> > Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> > --
> > No virus found in this incoming message.
> > Checked by AVG Anti-Virus.
> > Version: 7.0.344 / Virus Database: 267.11.13/124 - Release Date:
> 07/10/2005
> >
> > --
> > No virus found in this outgoing message.
> > Checked by AVG Anti-Virus.
> > Version: 7.0.344 / Virus Database: 267.11.13/124 - Release Date:
> 07/10/2005
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.13/124 - Release Date:
07/10/2005
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.13/124 - Release Date:
07/10/2005
This archive was generated by hypermail 2.1.4 : Sun Nov 06 2005 - 22:00:50 GMT-3