Dec
12

Many people have problems understanding the meaning of Bc (committed burst) used with traffic policing. Everyone seems to know the “magic” formula (Bc=1,5sec*CIR) but have a vague understanding of the reasons behind it. Let’s clear the confusion and see what Bc really affects when it comes to policing.

Averaging and Smoothing

Imagine you’re driving a car and want to find out your speed. In order to do this, you need to count the time (T) it takes you to pass the distance (S). The speed is then V=S/T – what a nice looking elementary school formula. So if you drove 100 miles in 1 hour your speed is 100 Mph. However, if you drove 50 miles in 30 minutes, your speed is the same 100 Mph. The only difference between the two measurements is the time interval used. Ideally, the only real value is your instant speed defined as the limit of S/T with T going to zero. However, this only works well in mathematics – in the real world, you always need a finite time interval to perform the measurement.

This finite time interval is called the averaging interval, as you only measure the average speed during the time span. You may have driven the first 50 miles in 15 minutes and the rest of the 50 miles in 45 minutes – but your average speed during one hour would still be 100Mps; even though it was an average of 200Mph during the first 15 minutes. It’s clear that a longer averaging interval allows for more speed variations within, while shorter intervals tend to measure the value closer to “instant speed”.

If you draw graphs of the speed measurement using different averaging intervals, you will quickly notice that the shorter intervals produce more oscillating, jerky graphs closer following the “instant” speed, while longer intervals result in smoothed graphs that lag in time behind the “instant” speed graph.

Traffic Policing and Averaging

The same averaging concept applies to traffic policing. The sole purpose of policing is comparing the average metered traffic rate with the CIR (committed information rate) and marking the packets that exceed it. The metering is essentially performed over the averaging interval Tc=Bc/CIR, where CIR is the metering rate. Therefore, the larger your Bc settings, the longer is the averaging time interval and the smoother is your speed measurement, allowing for speed oscillation within the time interval. So what’s better – a smaller Tc or bigger Tc? There is no answer, as they both measure the traffic rate correctly, just the bigger value allow for a more “unstable” traffic rate.

Flow Burstiness

Look at the figure below. Let’s say we set the policer to allow one packet per interval T. Then, the second packet of the RED flow will be rejected. However, if we set the policer to permit 2 packets in 2xT interval, both RED and GREEN flows will be admitted. In both cases, the CIR is the same.

traffic-policing-bursts

Based on this observation, we need larger averaging intervals for “bursty” flows, i.e. flows that tend to group packets in batches and space them with “silent” time intervals. Metaphorically, this corresponds to your car driving very fast and then very slow. One good example of a protocol with bursty traffic flows is TCP, as it sends all the packets it can send within the receiver window and waits for the TCP ACKs to open the sender window. This is especially noticeable with large RTT between the sender and receiver. For a single TCP flow, you may want to make sure the policer would admit a whole window of the outstanding packets, in order to avoid triggering the slow-start behavior if you drop the exceeding packets. The window size might be roughly calculated as RTT*CIR (if you assume the CIR be the maximum sender’s speed in situations where you limit the traffic rate using policing). If you take an average RTT of 1,5 seconds (that’s probably true for a very long network) you will get the “magic” formula from the above for Bc. However, in real life you may need to pick up the Bc value empirically, based on the actual application performance in situations where you use traffic policing to limit the traffic rate.

Summary

The original function of traffic policing was admission control at the edge of the network. However, policing is commonly used for traffic rate limiting in various situations due to performance benefits associated with policing implementations. Policing implicitly uses the averaging interval Tc=Bc/CIR to meter the average traffic rate. Larger Bc values allow for better accommodation of bursty traffic flows with oscillating traffic rates. Smaller Bc is good for stable flows, in situations where you don’t tolerate even a small violation of the instant traffic rate.

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website


You can leave a response, or trackback from your own site.

16 Responses to “The Meaning of Bc with Traffic Policing”

 
  1. tacack says:

    Great article petr! :)

  2. Andrei says:

    This was for sure the best description I’ve read. Thanks!

  3. Ian Finlayson says:

    Thanks Petr…

  4. Paul says:

    Hi Petr,

    Great article. Can you clarify something please?

    Is the “magic” 1.5 second rule for the rate-limit command only? Or does it apply to Class-Based Policing too?

    The documentation for the rate-limit command actually makes reference to the 1.5 second rule and gives the following example:

    rate-limit input access-group 1 17000000 3187500 6375000 conform-action transmit exceed-action drop

    (http://www.cisco.com/en/US/customer/docs/ios/qos/command/reference/qos_q1.html#wp1054922)

    But the documentation for the police command makes no reference to it and gives the following example:

    police 8000 1000 1000 conform-action transmit exceed-action set-qos-transmit 1 violate-action drop

    (http://www.cisco.com/en/US/customer/docs/ios/qos/command/reference/qos_n1.html#wp1046487)

    Thanks,
    Paul

  5. Swap says:

    Petr, u r the QoS king!

    Swap
    #19804

  6. Sam says:

    Hi Peter,

    Good article.
    In this ocassion i would request you to clarify something which is very basic but worth refreshing.

    I would like to know the values to be assumed in the CCIE lab while converting bits into bytes and back as well as to megabyte and megabits.

    Regards,
    Sam

  7. Jeriel says:

    hi

    Can anybody post an alternative to policing the traffic based on vlan? I am trying to use rate-limit on SVI but doesnt work,

    Regards

  8. cristian says:

    lets assume Bc is 1000bytes, 8000 bits police rate
    so in T0 Bc bucket full of tokens
    T0 : first packet arrive : 1 packet of 1000bytes ..so token bucket will
    become empty.
    T1 : after 0,5seconds another packet will arrive , 500bytes in size
    so by the time second packet arrive bucket will be refill with : 0,5 * police-rate / 8 = 500bytes => packet transmited

    In 0,5 seconds router sent 1500bytes, and my police-rate was defeted…

    where i get wrong…
    ?

    Thanks!

    • @cristian,

      The issue here is that you start with completely filled bucket. Thus an initial burst of 1000 bytes is permitted, but if packets will be arriving steady after this, without allowing the bucket to overfill at any moment, your sending rate will be 1000 bytes/sec on average.

      Imagine that after the T1 interval 0,5 seconds have lapsed and another 500 bytes packet has arrived. Your tocket bucket will permit it and you will have 2×500 bytes packet sent in 1 second. If every next packet will be arriving at the rate that does not let the tocket bucket overfill, you will get steady average 1000 bytes per second.

      The true problem is “rounding” – the size of tocken bucket is limited and overfilled tokens are wasted. To make averaging smoother you need to grow the bucket size, but this will allow for large “initial” bursts.

  9. cristian says:

    Yes Petr,
    that was the problem. that initial burst.
    in first second router cand send police_rate x2.
    after that only police_rate is allowed.

    Super. Thanks!

  10. Thomas says:

    Hi Pitr.

    As I understand policing (and CCO agrees with me) is that there is no averaging going on. Certainly no averaging over a time period as long as Bc/CIR.

    Tc doesn’t exist in policing (or is very very short. Like nanoseconds, and not changeable. Set in hardware)

    CCO link: http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800a3a25.shtml#tokenrefreshrate

    (first it shows shaping token refill, and then policing)

    Also this: “Interval defines how often tokens are removed from the bucket. Interval is fixed at 16 nanoseconds (16 sec *10-9). Interval cannot be changed.”

    http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800a3a25.shtml#tokenrefreshrate

    I have summarized my understanding of this at:

    http://blog.habets.pp.se/2010/01/Shaping-and-policing-on-Cisco

    If I’m wrong, please correct me.

    • @Thomas

      The problem is that CCO docs aren’t very clear as by what to mean under “averaging”. In addition, Cisco’s traffic shaping procedure combines both leaky and token bucket concepts which makes it truly confusing.

      By averaging you mean “scheduling packets at predefined intervals”. The blog post means “averaging traffic rate” over the interval. Thos concepts are inherently different: packet scheduling used in shaping enforces average rate, while packet meterer only meters it across the implicit interval of Tc=Bc/CIR.

  11. Thomas says:

    @Petr

    My point is that CCO doesn’t even mention averaging or Tc when talking about policing in the document I linked to (and others).

    It says that the token count is re-evaluated when a packet arrives at the policer, not periodically. And therefore no Tc.

    Note that some CCO docs talk about Tc and Tp in the context of policers, but then Tc means Token count in the Conforming/CIR bucket. (And Tp in the peak/PIR bucket).

    I have not seen one single document from Cisco that uses Tc time periods with policing (and I have looked), except as a fixed hardware token refresh rate. That rate is then on the order of nanoseconds or microseconds, not ms. Well, not more than a fraction of a ms. Certainly not Bc/CIR. To me then this Tc sounds more like the resolution of the hardware clock.

    Yours is not the only post that uses Tc (time periods) with policers, but I just can’t find any documentation from Cisco to actually back it up. Everything I find contradict it.

    See the links at the bottom of http://blog.habets.pp.se/2010/01/Shaping-and-policing-on-Cisco

    • henrique says:

      @Thomas,

      i’m at same trouble that you are. I see alot of people talking about TC in CB Policy but i didn’t found any official document about it. Incluinding Cisco Qos Exam certification Guide 642-642 by Wendell Odom and Michael Cavanaugh.

  12. [...] The meaning of Bc with Traffic Policing [...]

  13. [...] find more information about the use of Tc with traffic policing, look at the following publication: The meaning of Bc with Traffic Policing. Normally, either Tc or Bc value is explicitly defined in the contract, and for IP networks this [...]

 

Leave a Reply

Categories

CCIE Bloggers