From: Chris Lewis (chrlewiscsco@yahoo.com)
Date: Sun Oct 09 2005 - 14:06:51 GMT-3
Ryan,
You've got some excellent data here from Simon. As a first pointer I would suggest you forget about using Bc to be able to add a specific of bits per second to the policed rate. It does not work that way, utilization of burst in policiing depends on the way traffic arrives and only lets you go above the policed rate if you have built up credit, so it does not give you a guaranteed bits per second allocation that you can use when you want.
I wrote a similar description to what Simon posts recently in the archives at http://www.groupstudy.com/archives/ccielab/200509/msg00978.html
Chris
simon hart <simon@harttel.com> wrote:
Hi Ryan,
Point 1) No you cannot make up for your quota in the fourth interval,
unless you have Be set. And then it depends on the value of Be.
Point 2) The method of replenishing Be varies from algorithm to algorithm.
With Police MQC mechanism it is replenished when the Bc is overflowing. As
replenishing is based on packet arrival, then it is not based upon Tc as
such. With Traffic shaping it replenished at the end of a Tc, if Bc has
spare credit. With CAR the method is far more convuluted as it is based
upon Actual debt and compound debt.
Point 3) Only the packet using Be.
Don't worry about not getting this to begin with. I had real problems to
start with, persevere and you will get there.
HTH
Simon
-----Original Message-----
From: Private Ryan [mailto:pv.ryan@gmail.com]
Sent: 09 October 2005 16:27
To: simon hart
Cc: Chris Lewis; dusth@comcast.net; ccielab@groupstudy.com
Subject: Re: rate-limit vs. police
hi Simon,
Thanks for teaching me the concept of Bc and Be.
just want to know further
1) For Tc = 0.25s
If I send the traffic like 250,000bit , 250,000bit, 100,000bit in
first three Tc, can I send 400,000bit =250,000+150,000 in the 4th Tc
because the rate is 1,000,000bps
2) Be = 8000bit is only filled in every second ? or every Tc ?
3) In which case that DE bit will be set on frame-relay packet ? only
the packet using Be will be set as DE bit ?
My weakness in R&S Topics is QoS because I seldom touch it on my job.
=(
Thanks again !
Ryan
2005/10/9, simon hart :
> 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 :
> > 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 :
> > > ............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
> > >
> > >
This archive was generated by hypermail 2.1.4 : Sun Nov 06 2005 - 22:00:50 GMT-3