Re: 3560 Policer Burst Value

If you are talking about Individual rate policer, that works very well on
3560s, but things like aggregate-policer and on some IOSes Policed-dscp are
a little challenging, but you should be able to make them work.

On Thu, Sep 15, 2011 at 11:35 PM, Joe Astorino <joeastorino1982_at_gmail.com>wrote:

> ** I am familiar with the concept of aggregate policing of course and have
> configured it but have not applied it in the real world or studied the
> specific internals of bc in that aspect.
>
> The 3560 policing burst value is one I definitely think lacks good
> documentation. Even if you basically understand the concept of a single rate
> two color policer which it uses, the internals still have never "clicked"
> 100% at least for me with regards to bc calculation.
>
> With shaping bc makes total sense and I think is easier to grasp because we
> have that concept of a constant tc refresh period.
>
> With policing I can't seem to wrap my head around why the bc is literally
> the size of the bucket instead of the token refresh rate and what you should
> set it to to accomodate x bps of a constant traffic stream.
>
> With shaping the bc I believe is how many tokens are put in the bucket per
> tc, and I think the bucket is bc in size as well assuming no be. With
> policing it seems these are independent. In other words the bucket refresh
> rate is policed rate * time since last packet, and the size is defined by
> bc.
>
> Bah...kind of rambling sorry just a bit frustrated on this concept thanks
> and if someone has a way to understand the internals of the bc value
> specifically with cat qos policing please share!
>
> Sent from my Verizon Wireless BlackBerry
>
>
> Regards,
>
> Joe Astorino
> CCIE #24347
>
> "He not busy being born is busy dying" - Dylan
>
> ------------------------------
> *From: * Narbik Kocharians <narbikk_at_gmail.com>
> *Date: *Thu, 15 Sep 2011 22:39:52 -0700
> *To: *Pavel Bykov<slidersv_at_gmail.com>
> *Cc: *Joe Astorino<joeastorino1982_at_gmail.com>; Cisco certification<
> ccielab_at_groupstudy.com>
> *Subject: *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
>
>

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