Hi Joe,
I would say that this statement is not exactly correct. The underlying
concept of token bucket could be implemented in different ways. The
"per-packet" approach that you outlined is one of them. As you can
see, it triggers numerical calculations involving multiplication every
time a packet is switched. At a million packet per second rate this
might be CPU consuming.
Another approach would be running a periodic scheduler with some
acceptable rate say 8000 times a second, checking the size of the
token bucket and adding a quantum of tokens every interval. The
"scheduling" interval indeed has nothing to do with the Tc=Bc/CIR,
which is an "averaging" interval used for traffic policing (the larger
is Bc the more averaging policer performs while metering). Notice that
scheduler-based approach bounds the amount of CPU resources to say
just 8000 additions per second and thus is preferred for
hardware-optimized implementation. Not to mention that the addition
operation is much more CPU effective than multiplication. Of course,
the drawback of is limited metering precision ("resolution").
-- Petr Lapukhov, petr_at_INE.com CCIE #16379 (R&S/Security/SP/Voice) Internetwork Expert, Inc. http://www.INE.com Toll Free: 877-224-8987 Outside US: 775-826-4344 2009/12/11 Joe Astorino <jastorino_at_ipexpert.com>: > Another quick correction I wanted to make for everybody -- Contrary to > popular belief, the rate at which your token bucket or buckets refresh in > policing has nothing to do with a static value Tc like in shaping. The > number of tokens that get put back into your bucket depends on a calculation > the router does based on the interval of packets arriving. Every time a > packet arrives on the interface this gets checked and your tokens are added > as follows: > > Bc = ((Time of packet arriving - Time of previous packet arriving) * CIR) / > 8 > > This essentially gives us a "pro-rated" amount of tokens being refreshed > which makes sense. Imagine I am policing to 64Kbps. I get a packet at T = > 1 second and another at T = 2 seconds. At T = 1 second I get my CIR in > bytes placed into my bucket. At T = 2 I will have another CIR in bytes > placed into my bucket...say I get another packet at T = 2.5 seconds...OK > well now I only get .5 seconds worth of tokens instead of a full seconds > worth. > > On Fri, Dec 11, 2009 at 3:40 PM, Joe Astorino <jastorino_at_ipexpert.com>wrote: > >> Quick Edit: >> >> >> "If we are over the policed rate, but still within the max burst (Be in >> bytes) then we do something else based on the exceed action (usually drop or >> mark down)." >> >> What I meant to say was if we are over the max burst rate (Be) then we do >> something else entirely... So exceed with the single rate 2 color policer is >> "I went over Be". Sorry. >> >> >> On Fri, Dec 11, 2009 at 3:33 PM, Joe Astorino <jastorino_at_ipexpert.com>wrote: >> >>> Hi! >>> >>> This is certainly one of the more confusing topics : ) >>> >>> 1) The plain vanilla "police <bps>" command implements EITHER what we call >>> a single-rate two-color policer or a single rate three-color policer >>> depending on if you specify a violate action or not. In other words, with >>> no violate action defined we police based on only ONE rate, which would be >>> what you specify in bps in the command, and we can do certain things -- if >>> we are within the rate we "conform" and do some action (usually transmit). >>> If we are over the policed rate, but still within the max burst (Be in >>> bytes) then we do something else based on the exceed action (usually drop or >>> mark down). IF you choose to specify a violate action you are now >>> implementing a single-rate three-color policer. This is essentially the >>> same thing but more granular. Now you can say if I am within the policed >>> rate then I conform and do this thing...if I am over the rate but still less >>> than the Be that do something else (you went over the rate, but you are >>> still somewhere between the normal burst Bc and the max burst Be) and >>> finally if I am over the max burst do something else entirely. So you have >>> three options instead of two, hence the three colors. >>> >>> 2) The command "police cir" gets more "interesting" : ) When you do >>> police cir you are implementing a DUAL-rate three-color policer. This >>> introduces the whole concept of PIR. You are actually policing based on TWO >>> entirely different rates, as you actually have two separate token buckets >>> involved, Tc and Tp and you have different actions for each bucket being >>> policed. Essentially, you still have your three options (conform, exceed, >>> violate) but now exceed means "I went over the policed CIR rate but I am >>> still under the peak rate." The burst rate here would be related to the >>> first token bucket. Every Tc time interval you get Bc tokens in the first >>> bucket to play with. So essentially exceed means that you went over your >>> allotted Bc tokens per Tc and you need to wait for Bc to refill if you want >>> to send at that rate. The violate action here relates to the PIR and means >>> "I went over the policed CIR rate, AND I went over the PIR rate too...now >>> I'm screwed". The PIR rate relates to the 2nd token bucket you are policing >>> which gets Bc + Be tokens every Tc interval. >>> >>> 3) Remember that with policing your Bc and Be are specified in terms of >>> BYTES usually. Be careful. >>> >>> So in summary: >>> >>> police <bps> -- single rate two color OR single rate three color >>> depending on options. conform means within the bps rate. Exceed means you >>> went over the Bc rate and Violate means you are over Bc + Be. >>> police <cir> -- dual rate three color policer. conform means within the >>> CIR rate. Exceed means you went over policed rate of the FIRST bucket (Be). >>> Violate means you are over the policed rate of the SECOND bucket (PIR) >>> >>> HTH!!! >>> >>> >>> On Fri, Dec 11, 2009 at 3:04 PM, karim jamali <karim.jamali_at_gmail.com>wrote: >>> >>>> Dear Amr, >>>> >>>> The link brings a good understanding of Policing: >>>> >>>> http://wiki.nil.com/QoS_Policing_in_Cisco_IOS >>>> >>>> Petr's Policing vs Shaping article on INE Blog: >>>> >>>> >>>> http://blog.internetworkexpert.com/2008/07/03/at-a-glance-the-difference-between-shaping-and-policing/ >>>> >>>> >>>> I do believe in some sort or the other the values do correspond to each >>>> other (I mean shaping & policing values). >>>> The way it is explained is the token bucket; tokens are always added to >>>> the >>>> bucket in case of policing at the rate of the cir, when a packet comes, >>>> if >>>> enough tokens in the bucket exist to send the packet it is sent; >>>> otherwise >>>> it is discarded. >>>> >>>> Then the concept of PIR is introduced, it comes with some ISPs which will >>>> allow you to go above the CIR; filling the regular token bucket with the >>>> rate of CIR and an additional excess token bucket with the PIR rate. So >>>> now >>>> if a packet comes we will check if enough tokens (CIR+PIR) are available >>>> to >>>> send the packet otherwise it will be dropped. When both CIR & PIR are >>>> specified this is a dual token bucket where three actions can take place >>>> (Conform/Exceed/Violate). >>>> >>>> Police & Police cir as far as i believe do the same function. However >>>> police >>>> rate is used for control-plane policing(traffic destined to the control >>>> plane). >>>> >>>> Check this link for the difference between Police commands: >>>> >>>> >>>> http://www.cisco.com/en/US/docs/ios/12_3t/qos/command/reference/qos_o1gt.html#wp1090915 >>>> >>>> Best Regards, >>>> >>>> -- >>>> KJ >>>> >>>> >>>> Blogs and organic groups at http://www.ccie.net >>>> >>>> _______________________________________________________________________ >>>> Subscription information may be found at: >>>> http://www.groupstudy.com/list/CCIELab.html >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Regards, >>> >>> Joe Astorino CCIE #24347 (R&S) >>> Sr. Technical Instructor - IPexpert >>> Mailto: jastorino_at_ipexpert.com >>> Telephone: +1.810.326.1444 >>> Live Assistance, Please visit: www.ipexpert.com/chat >>> eFax: +1.810.454.0130 >>> >>> IPexpert is a premier provider of Classroom and Self-Study Cisco CCNA >>> (R&S, Voice & Security), CCNP, CCVP, CCSP and CCIE (R&S, Voice, Security & >>> Service Provider) Certification Training with locations throughout the >>> United States, Europe and Australia. Be sure to check out our online >>> communities at www.ipexpert.com/communities and our public website at >>> www.ipexpert.com >>> >>> >>> >> >> >> -- >> Regards, >> >> Joe Astorino CCIE #24347 (R&S) >> Sr. Technical Instructor - IPexpert >> Mailto: jastorino_at_ipexpert.com >> Telephone: +1.810.326.1444 >> Live Assistance, Please visit: www.ipexpert.com/chat >> eFax: +1.810.454.0130 >> >> IPexpert is a premier provider of Classroom and Self-Study Cisco CCNA (R&S, >> Voice & Security), CCNP, CCVP, CCSP and CCIE (R&S, Voice, Security & Service >> Provider) Certification Training with locations throughout the United >> States, Europe and Australia. Be sure to check out our online communities at >> www.ipexpert.com/communities and our public website at www.ipexpert.com >> >> >> > > > -- > Regards, > > Joe Astorino CCIE #24347 (R&S) > Sr. Technical Instructor - IPexpert > Mailto: jastorino_at_ipexpert.com > Telephone: +1.810.326.1444 > Live Assistance, Please visit: www.ipexpert.com/chat > eFax: +1.810.454.0130 > > IPexpert is a premier provider of Classroom and Self-Study Cisco CCNA (R&S, > Voice & Security), CCNP, CCVP, CCSP and CCIE (R&S, Voice, Security & Service > Provider) Certification Training with locations throughout the United > States, Europe and Australia. Be sure to check out our online communities at > www.ipexpert.com/communities and our public website at www.ipexpert.com > > > Blogs and organic groups at http://www.ccie.net > > _______________________________________________________________________ > Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html Blogs and organic groups at http://www.ccie.netReceived on Fri Dec 11 2009 - 21:13:43 ART
This archive was generated by hypermail 2.2.0 : Sat Jan 02 2010 - 11:11:08 ART