Re: 3560 Policer Burst Value

Joe,

I have tried many different values for Bc, especially when it comes to
policing on 3560. And i found that 250,000 works well no matter what the
policing rate is, NOW.....trying to understand reasons is always good, but
that philosophy only works when the equip that you are dealing with works
correctly. I think there are lots of issues with policing on these switches,
have you tried "aggregate-policer"? Once you try that you will see what i am
talking about. If you like, i can send you my labs and how i tested them.

On Thu, Sep 15, 2011 at 10:28 PM, Pavel Bykov <slidersv_at_gmail.com> wrote:

> In practice it's not as easy or straightforward, but once you know how to
> approach it, you can estimate the burst really quickly.
> With UDP stream that were mentioned, burst depends primarily on the
> consistent performance of the Head End, which usually is not, because
> usually it does not use real-time OS.
> With TCP it's all about window size and statistical aggregation.
> There are well defined general rules within the ITU-T.
> This document I found to be gold:
> http://www.itu.int/rec/T-REC-Y.1541/en
>
>
>
> On Fri, Sep 16, 2011 at 12:31 AM, Joe Astorino <joeastorino1982_at_gmail.com
> >wrote:
>
> > I am having a real hard time finding good information on this topic for
> use
> > in the real world. In the lab, we would usually just configure the burst
> > size we are told on a Cat 3560. I have done a LOT of reading on it, and
> > there are a lot of conflicting stories with regards to this.
> >
> > Basically, I am trying to find out how to calculate an optimal burst
> value
> > on a 3560 QoS policy doing policing. As you probably know the syntax
> looks
> > like this:
> >
> > police [rate in bits/s] [burst size in bytes]. Remember, this is
> policing
> > not shaping so the classic shaping formula of tc = bc/cir has no
> relevance
> > here mainly because the token refresh rate is not based on a static set
> > amount of time. The burst size is actually the size of the token bucket
> > itself in bytes, not a rate of any kind and it is filled as a function of
> > the policed rate and the packet arrival rate. The refill rate of the
> bucket
> > is not based on a static amount of time like in FRTS for example. It
> > basically says "how long was it since the last packet...multiply that
> times
> > the policed rate, and divide by 8 to give me bytes". In other words it
> > pro-rates the tokens. Makes sense.
> >
> > Anyways...I have found 2 sort of "methods" to calculating this, but they
> > are
> > so far off from one another I am not quite sure which one to use in the
> > real
> > world.
> >
> > Method 1: The classic CAR formula we see on routers: (rate * 1.5) / 8.
> > This basically gives you 1.5x the policed rate, and converts it to bytes.
> > Makes sense.
> > Method 2: 2x the amount of traffic sent during a single RTT.
> >
> > In my case, I am trying to police a video conferencing endpoint to 3Mbps
> so
> > by method 1 that gives me a burst size of 562,500 bytes. Using method 2,
> > let's just say I have an average RTT of 100ms. That method would yield a
> > burst size of 75,000 bytes. That is a HUGE difference
> >
> > This came about because the video endpoint was dropping frames. I
> noticed
> > the policed rate in the policy was 3,000,000 but the burst size was 8000
> > bytes (the lowest possible value). When I changed the burst based on a
> > 100ms RTT and the above formula the problem went away, but now I am
> having
> > doubts on the proper value to use here.
> >
> > Does anybody have any insight on how to actually calculate this properly?
> >
> > --
> > Regards,
> >
> > Joe Astorino
> > CCIE #24347
> > Blog: http://astorinonetworks.com
> >
> > "He not busy being born is busy dying" - Dylan
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Pavel Bykov
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
*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