From: Chris Lewis (chrlewiscsco@yahoo.com)
Date: Fri Oct 14 2005 - 15:45:41 GMT-3
Brian,
I hope you can clarify something in your reply below for me.
Mycurrent understanding does not seem completely in line with what you describe and I'd appreciate help in reconciling them.
The description you supply of Bc seems to reflect my understanding of how Bc operates in shaping, not how it operates in policing, and at the moment I believe they are quite different.
Bc in shaping is as described below, it defines the number bits available for transmission at each time interval, so that over a second, the CIR is transmitted. In policing Bc performs a different function, there is no queue in policing as there is in shaping. This fundamental difference drives the policer algorithm to be different than the shaping algorithm for adding tokens.
For policing, if packets are arriving say every 100 msecs, but at a rate that is below the policed rate, credit will be built up. Then if a set of packets comes along that would temporarily mean the policer has to exceed the policed rate in order to average out at the policed rate over a second, Bc can be used to allow that to take place.
The way this relates to the token bucket is that tokens are only added to the bucket when a packet arrives for policing (whereas they are added at regular intervals for shaping). The tokens are only added at a net rate equivalent to the policed rate, and the depth of the bucket equals the Bc rate. Having this tunable depth of bucket allows the bursting above the policed rate on a temporary basis in order to meet the averaged policed rate and is necessary as policiing cannot store up packets for transmitting at a later time interval as shaping can.
My understanding is based off reading the following link, please advise if I've misread something.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123tcr/123tqr/qos_o1gt.htm#wp1084068
Chris
Brian McGahan <bmcgahan@internetworkexpert.com> wrote:
Mike,
Changing the Bc in policing affects how often you are enforcing
the policed rate. A lower Bc means that you are policing to a smaller
rate more often over the second, while a higher Bc means the opposite.
In either case you will still police to the same aggregate rate over the
second, but how traffic bursts are propagated will be different.
Remember that 1 second to the router is a huge amount of time.
On a Gigabit interface you have the capability to encapsulate 1 billion
bits in that single second. Suppose that you're sending 100 Megabits
worth of traffic in one second on this interface. If you send 1 Megabit
in the first 500ms and then 99 Megabits in the last 500ms the policing
interval would affect this differently than if you had sent 1 Megabit
evenly every 10ms.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Mike Ollington
> Sent: Friday, October 14, 2005 11:34 AM
> To: Chris Lewis; simon hart; Private Ryan
> Cc: dusth@comcast.net; ccielab@groupstudy.com
> Subject: RE: rate-limit vs. police
>
> Hi,
>
> I'm trying to figure what the application would be for modifying the
Bc
> to be non-default in CB-policing.
>
> What could I gain by increasing or decreasing the value? In shaping,
Bc
> is modified to affect Tc. Shorter Tc intervals mean less latency is
> induced.
>
> Thanks,
> Mike
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Chris Lewis
> Sent: 09 October 2005 18:07
> To: simon hart; Private Ryan
> Cc: Chris Lewis; dusth@comcast.net; ccielab@groupstudy.com
> Subject: RE: rate-limit vs. police
>
> 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 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:51 GMT-3