Re: Traffic Conditioning

From: Petr Lapukhov (petr@internetworkexpert.com)
Date: Thu Jul 06 2006 - 06:12:15 ART


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



This archive was generated by hypermail 2.1.4 : Tue Aug 01 2006 - 07:13:46 ART