From: Carlos G Mendioroz (tron@huapi.ba.ar)
Date: Thu Oct 21 2004 - 18:28:28 GMT-3
No typo there.
The PIR token bucket is up front, the CIR token bucket is applied after.
gladston@br.ibm.com wrote:
>
> Thanks you Guys,
>
> I wish you wrote the CD Doc (life would be easier :) )
>
> ========
> quoted
> The rate of filling of the first bucket is PIR, and its size is Be.
> ========
>
> I am sure it was a typo and you mean the second bucket.
>
>
>
>
>
> Carlos G Mendioroz <tron@huapi.ba.ar>
>
> 21/10/2004 08:51
>
>
> To
> Bob Sinclair <bsinclair@netmasterclass.net>
> cc
> Alaerte Gladston Vidali/Brazil/IBM@IBMBR, ccielab@groupstudy.com
> Subject
> Re: Two Rate Policer
>
>
>
>
>
>
>
>
> To be direct on Gladston question, yes.
> Two token and two rate are different things.
>
> To understand the difference you have to learn what the (token) buckets
> are used for.
>
> In one bucket alg, there is one bucket which is filled at certain rate
> (bps, Bps, pps or the unit at hand) and that has some capacity (in bits,
> bytes or packets).
> To be able to transmit, you have to take enough "credits" from the
> bucket. The problem is that if you don't transmit, then you can
> accumulate only the bucket's capacity. Once the bucket is full, overflow
> credits are lost.
> And if you want to transmit a lot, you can burst as much as capacity at
> once but then have to wait for more credits that arrive at fill rate.
>
> Fill rate is CIR. Bucket capacity is Bc (CBS in RFC parlance). The
> algorithm is also dubbed two color, because at a given packet, it can
> have two outputs: ok/not ok. (conform/exceed)
>
> Then you have two ways of extending this with another bucket:
> RFC2697 has another bucket to get credits that overflow the first bucket
> up to a certain extra capacity. Then, if you want to transmit and first
> bucket credits are not enough, you can take from the second bucket.
> If that's ok, then you have "exceed" action, if that's not enough, you
> have "violate". Thus you have a three color marker, and still a single
> rate. The second bucket size is Be (EBS in RFC parlance).
>
> RFC2698 makes it differently. Instead of having a second bucket to get
> the overflown credits, you put another bucket similar to the first in
> front of it, with a new rate and a new capacity. This gives you another
> marker that is used up front and if you don't conform, you get the
> violate action. But if you do, you go to the second (original) bucket
> and now you get either conform or exceed.
> Note that a conforming packet uses credits from both buckets!
> The rate of filling of the first bucket is PIR, and its size is Be.
>
> To complete (and complicate) the the thing, "filling" operations are
> synchronous and happen at regular intervals. That's Tc. This is not
> strictly conformant with RFC, which asks for CIR times per second
> updates of size 1, but it fits the frame relay way.
>
> HTH
>
>
> Bob Sinclair wrote:
> > Gladston,
> >
> > The major difference between the single-rate and two-rate policer is in
> > how tokens get into a second bucket. In the single-rate policer,
> > tokens are placed into the second (Be) bucket only when you are below
> > the the average rate. It acts like a savings account to let you burst
> > above cir. With the two-rate policer the buckets are filled
> > independently, you do not have to go below cir in order to put tokens
> > in the second bucket.
> >
> > By analogy, the single rate policer is like getting a $10/week
> > allowance. The only way you can spend $15 in a week is to save $5 from a
> > previous week. The two rate policer is like getting two allowances per
> > week - $10 from your parents and $5 from your grand parents. You can
> > spend $15/week without having to first save.
> >
> > If you want a three-color marker (conform, exceed, violate), you can use
> > either method. The RFCs (2697 and 2698) say that the single-rate is
> > most useful when the it is the LENGTH of a burst, not its peak rate that
> > determines service elilbility. The two-rate is most useful when peak
> > rate needs to be enforced separately from a committed rate. The two-rate
> > method allows for a sustained excess rate, and seems easier to
> > configure, to me, but it really depends on the traffic profile you want
> > to enforce.
> >
> > HTH,
> >
> > Bob Sinclair
> > CCIE #10427, CISSP, MCSE
> > www.netmasterclass.net
> >
> > ----- Original Message ----- From: <gladston@br.ibm.com>
> > To: <ccielab@groupstudy.com>
> > Sent: Wednesday, October 20, 2004 4:44 PM
> > Subject: Two Rate Policer
> >
> >
> >> Kind of confuse with this statement:
> >>
> >> =================
> >> quoted
> >> this feature was available, you could police traffic with the
> >> single-rate Traffic Policing feature.
> >>
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t4/ft2rtplc.htm
> >>
> >> ================
> >>
> >> Because this another Cisco URL seems to says it differently:
> >> ================
> >> quoted
> >> There are currently two types of token bucket algorithms: a single
> >> token bucket algorithm and a two token bucket algorithm. A single
> >> token bucket system is used when the violate-action option is not
> >> specified, and a two token bucket system is used when the
> >> violate-action option is specified.
> >>
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t2/ftpoli.htm
> >>
> >> =================
> >>
> >>
> >> Am I taking an erroneous assumption that "single-rate" and single
> >> token" are the same terms?
> >>
> >> Behind that question is that it is not clear to me what task would
> >> require using one or another.
> >> police cir pir
> >> or
> >> police (bps) (burst-normal)...
> >>
> >> _______________________________________________________________________
> >> 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
> >
>
> --
> Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
>
-- Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
This archive was generated by hypermail 2.1.4 : Sat Nov 06 2004 - 17:11:51 GMT-3