From: Private Ryan (pv.ryan@gmail.com)
Date: Mon Oct 10 2005 - 12:47:30 GMT-3
Thanks both Simon and Chris for this valuable information.
Ryan
2005/10/10, Chris Lewis <chrlewiscsco@yahoo.com>:
> 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
> > > >
> > > >
> _______________________________________________________________________
> > > > 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
> >
> >
> _______________________________________________________________________
> > 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
> >
> >
> --
> 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
>
>
> ________________________________
> Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
This archive was generated by hypermail 2.1.4 : Sun Nov 06 2005 - 22:00:50 GMT-3