From: Private Ryan (pv.ryan@gmail.com)
Date: Sun Oct 09 2005 - 12:26:55 GMT-3
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 <simon@harttel.com>:
> 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
>
> _______________________________________________________________________
> 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