Re: 3560 Policer Burst Value

For policing I think the Bc value is better to be safe than sorry, and
making it larger doesn't really hurt you. ( except that you will have an
initially higher burst of traffic after a period of inactivity - this may be
a problem for some). But overtime it will average out to the configured CIR
no matter what, because policing refills the token bucket at a rate
determined by the CIR.

It's not like with Traffic Shaping where a large Bc value could adversely
affect delay sensitive traffic.

-Yuri

On Fri, Sep 16, 2011 at 11:48 AM, Narbik Kocharians <narbikk_at_gmail.com>wrote:

> I do understand that caps have a meaning, but this is what Joe wrote:
>
> Assumptions:
> Interface is connected at 100Mbps
> Policed rate is 3Mbps
> Burst Size is set to 8000 Bytes
> Ethernet frame size is a maximum 1500 bytes
>
> and i have never hear the police rate in Bytes before.
>
> On Fri, Sep 16, 2011 at 11:43 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar
> >wrote:
>
> > Well, if my number had been 3Mbps, yes, but I was thinking bytes
> > and that was the reason for the 3MBps. Caps do have meaning after all.
> >
> > I did change the units Joe used, though. Sorry if that caused some
> > confusion.
> >
> > -Carlos
> >
> >
> > Narbik Kocharians @ 16/09/2011 15:23 -0300 dixit:
> >
> >> Carlos,
> >>
> >> Shouldn't you divide 3000,000 by 8 or multiply 1500 by 8 before you do
> the
> >> division?
> >>
> >> On Fri, Sep 16, 2011 at 10:37 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar
> <mailto:
> >> tron_at_huapi.ba.ar>> wrote:
> >>
> >> Joe,
> >> I think that your initial settings call for the policer to kick in
> >> really fast, after all, you are policing @3MB and sending @100MB!
> >>
> >> The idea of the policer is that if 3MBps are ok, then 1500 byte
> packets
> >> should arrive @ 3000000/1500 = 2000 pps, or every .0005s.
> >> Then, if even spaced, t - t1 * policed rate yields 1500 and all is
> >> good.
> >>
> >> If your source is CBR, all that makes the burst size important is
> >> jitter
> >> (IPDV in Pavel referred document). Video is a whole different story,
> as
> >> it is not CBR, but VBR. (Constant Bit Rate, Variable Bit Rate).
> >> VBR codecs tend to have different design behaviours. An altogether
> >> different problem.
> >>
> >> -Carlos
> >>
> >> Joe Astorino @ 16/09/2011 13:49 -0300 dixit:
> >>
> >> PS I know these numbers are WAY off, but at least I think it
> >> makes the concept of how the burst works make more sense, at
> >> least for me. I think in the real world, there are many many
> >> other factors like the video codec being used, number of bytes
> >> in the payload of each packet, number of packets per second, etc.
> >>
> >> On Fri, Sep 16, 2011 at 11:44 AM, Joe Astorino
> >> <joeastorino1982_at_gmail.com <mailto:joeastorino1982_at_gmail.**com<
> joeastorino1982_at_gmail.com>
> >> >
> >> <mailto:joeastorino1982_at_gmail.**__com
> >>
> >> <mailto:joeastorino1982_at_gmail.**com <joeastorino1982_at_gmail.com
> >>>>
> >> wrote:
> >>
> >>
> >> OK, I have worked this out, at least in my own head to make
> >> sense. I thought I would share with you guys. A lot of this
> >> is based on
> >> assumptions, but at least it makes sense to me:
> >>
> >> Here is how I see things playing out with an 8000 byte burst
> >> size
> >>
> >> Assumptions:
> >> Interface is connected at 100Mbps
> >> Policed rate is 3Mbps
> >> Burst Size is set to 8000 Bytes
> >> Ethernet frame size is a maximum 1500 bytes
> >>
> >> By this logic, if the host is connected and sending at
> >> 100Mbps, and
> >> he is sending 100,000,000 bits per second or 12,500,000 bytes
> >> per
> >> second. If each frame is 1500 bytes, it is sending 12,500,000
> /
> >> 1500 or about 8333 frames per second. That means every 1/8333
> >> seconds or .00012 seconds a 1500 byte frame arrives at the
> >> switch
> >> port and is evaluated against by policer.
> >> When the policer sees the frame, it first adds tokens to the
> >> bucket
> >> based on the formula (t1 - t) * policed rate where t1 is the
> >> packet
> >> arrival time and t is the last packet arrival time. This is
> in
> >> bytes so... every .00012 seconds a frame arrives and the
> policer
> >> puts 45 bytes into the bucket (3,000,000/8 * .00012).
> >> Obviously,
> >> this is a very low number and I think explains why the 8000
> byte
> >> limit couldn't handle the bitrate
> >>
> >> After not too many intervals of 1500 byte frames coming in at
> >> .00012
> >> seconds, the BC bucket would be empty. Now...lets run the
> >> math with
> >> the BC size I have chosen, 37,500 bytes. All the other
> >> assumptions
> >> are the same here. BC_Size is the size of BC at the beginning
> >> of
> >> the interval
> >>
> >> Time: 0
> >> BC_Size: 37,500
> >>
> >> send the 1500 byte frame, leaving BC at 36,000 bytes
> >>
> >> Time: .00012 seconds
> >> BC_Size: 36,000 bytes
> >>
> >> add 45 bytes to the bucket, send the 1500 byte frame leaving
> >> BC at
> >> 34,545 bytes
> >>
> >> Time: .00024 seconds
> >> BC_Size: 34,545 bytes
> >>
> >> add 45 bytes to the bucket, send the 1500 byte frame leaving
> >> BC at
> >> 33,090 bytes
> >>
> >> Time: .00036 seconds
> >> BC_Size: 33,090 bytes
> >>
> >> add 45 bytes to the bucket, send the 1500 byte frame leaving
> >> BC at
> >> 31,635
> >>
> >> ...
> >>
> >> Now, with that math the rate can be sustained for about 28
> >> intervals
> >> until the bucket is emptied and packets would start being
> >> dropped. So...that still doesn't really work because 28
> >> intervals only takes
> >> us until .003 seconds until the bucket would be flattened.
> >> But then
> >> again, my assumptions could be way off. Everything is based
> >> on the
> >> idea that the unit is sending at the negotiated speed of
> >> 100Mbps and
> >> that is is constantly sending a stream of fixed length 1500
> byte
> >> packets. That could be WAY off, but at least now having
> really
> >> thought through it, I think I have a better understanding.
> >>
> >> If anybody here knowledgeable on the subject happens to read
> >> this
> >> and think I'm off my rocker, please enlighten me I'd love to
> >> understand deeper.
> >>
> >> - Joe
> >>
> >> -- Regards,
> >>
> >> Joe Astorino
> >> CCIE #24347
> >> Blog: http://astorinonetworks.com
> >>
> >> "He not busy being born is busy dying" - Dylan
> >>
> >>
> >>
> >>
> >> -- Regards,
> >>
> >> Joe Astorino
> >> CCIE #24347
> >> Blog: http://astorinonetworks.com
> >>
> >> "He not busy being born is busy dying" - Dylan
> >>
> >>
> >> -- Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:
> tron_at_huapi.ba.ar
> >> >>
> >>
> >> LW7 EQI Argentina
> >>
> >>
> >>
> >> Blogs and organic groups at http://www.ccie.net
> >>
> >> ______________________________**______________________________**
> >> _______________
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/__**list/CCIELab.html<
> http://www.groupstudy.com/__list/CCIELab.html>
> >> <http://www.groupstudy.com/**list/CCIELab.html<
> http://www.groupstudy.com/list/CCIELab.html>
> >> >
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >> *Narbik Kocharians
> >> *CCSI#30832, CCIE# 12410 (R&S, SP, Security)
> >> *www.MicronicsTraining.com* <http://www.micronicstraining.**com/<
> http://www.micronicstraining.com/>
> >> >
> >>
> >> Sr. Technical Instructor
> >> YES! We take Cisco Learning Credits!
> >> Training & Remote Racks available
> >>
> >>
> > --
> > Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
> >
>
>
>
> --
> *Narbik Kocharians
> *CCSI#30832, CCIE# 12410 (R&S, SP, Security)
> *www.MicronicsTraining.com* <http://www.micronicstraining.com/>
> Sr. Technical Instructor
> YES! We take Cisco Learning Credits!
> Training & Remote Racks available
>
>
> 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.net
Received on Fri Sep 16 2011 - 12:34:48 ART