From: Jung-I Lin (easyman.lin@gmail.com)
Date: Fri Jul 07 2006 - 05:56:29 ART
Hi, Victor
Long time no see. :)
I think the description of packet 6 is correct.
It states that " After packet 5 is dropped, the compound debt resets
to 0. However, the actual debt of 2 remains(because packet 5 is drop
so actual debt = 3-1 = 2)."
Then packet 6 incoming, and the actual debt = 2 + 1(6th packet) = 3,
and compound debt is 3 + 0(reseted compound debt) = 3
There is another good description of Policing by Chris Lewis.
You can get it from
http://www.groupstudy.com/archives/ccielab/200509/msg00978.html
And btw, Thanks for the great clairfication by Petr.
You did a very good example for understanding about the concept.
Are you also a instructor of IE ?
Thanks
Jung-I
On 7/6/06, Victor Cappuccio <cvictor@protokolgroup.com> wrote:
> THANK YOU MAN,
>
>
>
>
>
>
>
> _____
>
> De: petrsoft@gmail.com [mailto:petrsoft@gmail.com] En nombre de Petr
> Lapukhov
> Enviado el: Jueves, 06 de Julio de 2006 05:12 a.m.
> Para: Victor Cappuccio
> CC: ccielab@groupstudy.com
> Asunto: Re: Traffic Conditioning
>
>
>
> Victor,
>
> you should clearly understand that policing is a "metering" system,
> that has no periodic Tc pulses at all.
>
> For example, imagine 100Mbs interface and inbound 10Mbs policer. You have
> packets arriving on interface at *line speed*, linearly, in sequenced
> fashion.
> That is, every packet arrives at wire speed = 100Mbs.
>
> Depending on inter-packet timing you may get "dense" or "sparse" traffic
> bursts (group of "packed" packets):
>
> ---PPP--P-P-P-PPPP-----
>
> If you have flow "packed" densely, you reach up line rate of 100mbs.
> From interface standpoint you have something like that on liner time-scale:
>
> PPPPPPPPPPP
>
> So, what does policer rate = 10Mbs means? Well, it should be some sort
> of *average* traffic-rate value! If we receive full load of 100Mbs, but drop
> every
> second packet, we get approximate average rate of 50Mbs, right :)?
>
> ----PXPXPXPXPXPXPXPXP--
>
> Every packet arrives at 100Mbs... but if you tak byte count over some time
> interval, you will get "average" rate less than 100Mbs.
>
> To calculate an average in some formal manner, you need a bunch of packets
> to summarize - simple mathematical idea :) You just can't wait all life to
> count all packets, right? :) So here comes the concept of burst.
>
> Burst is simply a group of packets. How could you measure average
> bitrate of a burst? You take burst size in bytes and divide in by (t1-t0),
> where
> t1 is last packet arrive time, and t0 is first packet arrival time. That is,
> if you
> take different burst sizes (number of packets) you may get different average
> rates. The bigger is burst value, the more "smoothing on spikes" you do.
> That
> is, you permit quick speed oscillation (over 10Mbs) "inside" your burst.
>
> The net result is that you have defined "metering" procedure:
>
> If you take "burst" bytes of output packets from a policer, and divide it
> by
> (t1-t0) value, you will get rate specified by policer. That is, sure, if you
> have
> you policer "loaded" with incoming traffic.
>
> ----
>
> A few words for CAR Be and actual/compoud debt. This is a "cisco-specific"
> algorithm, which has actually nothing with metering. It was implemented to
> simulate RED behavior on TCP traffic, and is totally RFC non-conformant.
>
> "Be" value with RFC policer is used to "meter" how big a "legal" spikes of
> traffic could be, to control "overbursting" in some way. Two-rate policer
> permits you to meter and police "overburst" speed too.
>
> HTH
> --
> Petr Lapukhov, CCIE #16379
> petr@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com <http://www.internetworkexpert.com/>
> Toll Free: 877-224-8987
> Outside US: 775-826-4344
>
> 2006/7/5, Victor Cappuccio <cvictor@protokolgroup.com>:
>
> Hello,
>
> QoS Gurus, I need your attention please.
>
> I'm having a hard time to understand the values of Normal Burst and Exceed
> Burst. I know that those values are in Bytes and that the Token Bucket (same
> as Bc+Be) is used as a metaphor to explain how tokens are removed from the
> bucket in a relation to a packet size, and also tokens are added to the
> bucket every TC.
> Also I think that I understand the logic behind the Policing compound and
> actual debt algorithm, BTW in Table 1 of this link
> http://www.cisco.com/en/US/products/sw/iosswrel/ps5014/products_feature_guid
>
> e_chapter09186a00800ca4f2.html at Pkt 6 the Actual Debt is wrong, it should
> be 3 and not 2 as the description says. Also that the Token measurement
> method in Class Based Policing separate token buckets for burst-normal and
> burst-max and that in the legacy configuration (car) single token bucket for
>
> burst-normal and burst-max (definitions of RFC 2697 and 2698)
>
> but I got stuck in the implementation and interpretation :S
>
> For example yesterday I lab something really stupid, Running RIP in all
> interfaces (so reachability is not a problem here)
>
> Lo0- R3 .. serial .. R1 ----- Ethernet ---- R2
>
> I changed the point-to-point circuit clock rate to different values for
> testing, and I did a ping with different packet sizes from R2 to R3 lo0, and
> also applied at R1 a rate-limiter with different values, but I could not
> interpret the values showed show int XX rate, I saw packets fragmented, I
> saw different values for the rate, I got frustrated.
>
> Is there any ordered way to test this and finally understand it
>
> I think that an example using ping with different sizes and with different
> policing values would be very helpful, is there any link out there with
> that, or I'm asking to much, if so please sorry for the spam
>
> I mean I can not afford to buy more books, because my budget is in 0 now, so
>
> please if you do not mind, shed a light here.
>
> Thanks
> Victor.-
>
> PS:
> I do not understand well yet what the Word Burst means (in Spanish is
> something really different of what you can think, is like killing someone
> :D),
>
> _______________________________________________________________________
> 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
>
-- Thanks Best Regards,Jung-I Lin
This archive was generated by hypermail 2.1.4 : Tue Aug 01 2006 - 07:13:46 ART