Understanding Single-Rate and Dual-Rate Traffic Policing

8/17/2019 Understanding Single-Rate and Dual-Rate Traffic Policing

1/12

Tweet

Blog Home | INE Home | Members | C o n ta ct U s | Su b scri b e

Free Resources

View Archives

All Access Pass

CCIE Bloggers

May22

Understanding Single-Rate and Dual-Rate Traffic Policing21 Com mentsPos ted by Petr Lapuk hov , 4x CCIE/CCDE in QoS

This blog post reviews and compares two most common types of traffic contracts – single rate anddual-rate agreements and their respective implementations using single-rate and dual-rate (two-rate) policing.We are also going to briefly discuss effects of packet remarking on end-to-end throughput and finally look atsome examples of IOS configuration.

What is Traffic Contract

Service-providers network topology typically follows core/aggregation model, where network core has meshedtopology and aggregation layers use some v ariation of tr ee topology. This design results in bandwidthaggregation when flows converge toward the core. Therefore, to avoid network resource oversubscription,accurate admi ssion control is necessary at the network edge. The admission operation was trivial with circuit-switched TDM-based networks, but became significantly more complicated in packet switched networks. In apacket network, there is no such thing as a constant traffic flow rate, as flows only exist “temporarily” whenpackets are transmitted. In packet networks, it is common for service providers to connect customer using asub-rate connection. Sub-rate a connection that provides only a fraction of the maximum possible linkbandwidth, e.g. 1Mbps on a 100Mbps connection.

Implementing sub-rate access requires special agreement between service provider and customer – aspecification known as “traffic contract”. Traffic contracts are enforced both at customer and SP sides by using

traffic shaping and policing respectively. Traffic contracts may vary and include multiple QoS parameters, butthere are two most common types that we are going to look at today: single-rate and dual-rate traffic contracts.

Single Rate Traffic Contract

Single-rate traffic contract is normally defined for a sub-rate connection over a physical link with maximumtransmission rate of AR (Access Rate). There are three main parameters associated with this type of contract:

Committed Information Rate (CIR). Defines the average traffic rate that a customer is allowed to sendtraffic into the network. Notice the term “average” as packets are still being sent at the line rate (AR), andthe information rate is defined by averaging measurement over some time interval. Per the definition, CIRis assumed to be less than AR

Committed Burst Size (Bc). This value defines the maximum amount of contiguous packets that acustomer is allowed to send in a single “batch”. Packet traffic is commonly bursty, e.g. TCP connection isnormally “clocked” by the rate of incoming TCP ACK’s, and the burst size is typically two segments,though the sender may send up to a full TCP window, when possible. After a customer has sent acontiguous block of “Bc” bytes, it must pause for some time before sending the next batch. This isnormally implemented using traffic-shaping at customer side.

http://blog.ine.com/?author=5http://www.ine.com/about-us.htmhttp://blog.ine.com/archiveshttp://blog.ine.com/http://www.ine.com/http://members.ine.com/http://www.ine.com/contact.htmhttp://feeds.feedburner.com/ine/http://blog.ine.com/http://blog.ine.com/http://-/?-http://blog.ine.com/category/ccie-routing-switching/qos/http://blog.ine.com/?author=5http://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/http://www.ine.com/about-us.htmhttp://www.ine.com/all-access-pass-subscription.htmhttp://blog.ine.com/archiveshttp://www.ine.com/resources/http://feeds.feedburner.com/ine/http://feeds.feedburner.com/ine/http://www.ine.com/contact.htmhttp://members.ine.com/http://www.ine.com/http://blog.ine.com/http://blog.ine.com/https://twitter.com/intent/tweet?original_referer=http%3A%2F%2Fblog.ine.com%2F2011%2F05%2F22%2Funderstanding-single-rate-and-dual-rate-traffic-policing%2F&ref_src=twsrc%5Etfw&text=Understanding%20Single-Rate%20and%20Dual-Rate%20Traffic%20Policing&tw_p=tweetbutton&url=http%3A%2F%2Fblog.ine.com%2F2011%2F05%2F22%2Funderstanding-single-rate-and-dual-rate-traffic-policing%2F&via=ine


2/12

Excessive Burst Size (Be). This is a non-mandatory parameter that could be used to improve admissioncontrol “fairness”. Let’s say a customer connection has been idle for some time, and then customer gotnew traffic to send. Regardless of the previous idle interval, only Bc bytes could be sent in a single burst,and after that customer needs to wait and accumulate more sending credit. By allowing customer toaccumulate up to Be extra bytes during longer than normal wait intervals, it is possible to compensate for idle times and send Bc+Be bytes momentarily for a short time. Notice that longer-term average rate stillremains equal to CIR, the excessive bursting mechanism only allows for occasional bursting.

Pay attention to the implicit value of Tc=Bc/CIR – this time interval is known as metering “averaging interval”. It

defines a time window to count bytes in traffic flow for the purpose of finding the average rate. You may findmore information about the use of Tc with traffic policing, look at the following publication: The meaning of Bcwith Traffic Policing. Normally, either Tc or Bc value is explicitly defined in the contract, and for IP networksthis value should be large enough to allow efficient work of TCP end-to-end between customer locations.Therefore, the lowest value of Tc (or Bc) is effectively based on the SP SLAs and RTT times from onecustomer site to another. At the very least, the equation Bc >= CIR*RTT should hold, where RTT is themaximum round-trip time site-to-site, per the SLA. At this moment, it is worth reminding that QoS tools areused to control connection quality end-to-end between two different sites connected to the same SP, or different SPs that share some sort of QoS agreements. It is important to point out that that in order to allow for any QoS, complete network should be under the control of a service provider.

What about the Be value? If this one is ever used in contract, it defines the amount of “unused time intervals”

that could be “reclaimed” back by the sender. If the customer is allowed to reclaim back N*Tc intervals, thenBe could be found simply as N*Bc. Most commonly, if Be is used, N equals to 1, which means the customer may reclaim a single “wasted” Tc interval. The more you grow Be, the more fair would the bandwidth utilizationlook to a customer, but the sporadic peak rates would tend to exceed CIR more than normal. There is no“best” value for Be, it depends on type of traffic.

Implementation wise, single-rate traffic policing is implemented by tracking the current burst size using token-bucket mechanics, and discarding packets that exceed CIR. The so-called, Single-rate, Three-Color Marker (srTCM) is the RFC name for ingress tool used to implement admission control at the network edge. The“three color” term means that any incoming burst could be classified as either conforming (green, under Bc),exceeding (yellow, over Bc but under Be) or violating (red, over Be). Depending on the implementation,exceeding packets could be admitted, but have their QoS marking changed to show higher drop precedence

in the network core. Here is how the srTCM implementation looks like on a diagram:

Pay attention to the fact that there is a single flow of the tokens that fills the Bc bucket (CBS, committed burstsize) first and then continues to filling the Be bucket (EBS, excess burst size). The second bucket is only filledif there was enough idle time to let the first bucket fill up completely. Every arriving packet is first compared toCBS and then to the EBS to determine the next action. The “Ti” interval is the special periodic timer that isused to add tokens to the token buckets. Ideally, Ti should be 1/CIR, but this is normally not possible due to

limited resolution of hardware clock, so a small enough value of Ti is chosen.

Dual Rate Traffic Contract

The drawback of single-rate traffic contracts is that SP should be cautions assigning CIR bandwidth, and may

http://blog.ine.com/wp-content/uploads/2011/05/srTCM.pnghttp://blog.ine.com/2009/12/12/the-meaning-of-bc-with-traffic-policing/


3/12

effectively “undersell” itself, by offering less bandwidth than it can actually service at any given moment of type. The reason for this is the fact that not all customers send traffic simultaneously, so network links mayeffectively become underutilized even at the “weak spots”. This brings the idea of dual-rate traffic contract:supply customer with two sending rates, but only guarantee the smaller one. In case of congestion in thenetwork, discard traffic that exceeds the committed rate more aggressively and signal the customer to slowdown to the committed rate. This principle was first widely implemented in Frame-Relay networks, but couldbe easily replicated using any packet-switching technology. There are four main parameters in a dual-ratetraffic contract.

Committed information Rate (CIR). Same meaning as with a single-rate contract.Committed burst size (Bc). Same meaning as with a single rate contract, and once again, Tc – theaveraging interval – is implicitly defined as Tc=Bc/CIR.Peak Information Rate (PIR). Additional parameter – defines the maximum average sending rate for thecustomer. Traffic bursts that exceed CIR but remain under PIR are allowed in the network, but marked for more aggressive discarding. Marking depends on the transport technology, e.g. it could be DSCP bits,

ATM CLP or Frame-Relay DE bit.Excessive Burst Size (Be). This value has different meaning, compared to a single-rate contract. Be isthe maximum size of the packet burst that could be accepted to sustain the PIR rate. Effectively, Bedefines the second averaging interval, Te=Be/PIR, the averaging rate for PIR metering. Keep in mind that

just like with any packet networks packets are sent at the AR, the actual physical rate – CIR and PIR are just average values.

Compared to a single-rate traffic contract, dual-rate has two major differences. Firstly, incoming traffic burstsare metered and compared to CIR and PIR rates simultaneously, using the corresponding Bc and Be burstsizes. Depending on the comparison results, different actions could be taken with regards to the packets.Normally, if a burst is under CIR, it is admitted into the network without any modifications. If the burst exceedsCIR, but remains under PIR (e.g. current burst is still under Be), the burst has marking changed, but stilladmitted into the network. Finally, if the burst exceeds PIR, it is typically being discarded. Dual-rate contractsare normally implemented using some sort of two-rate, three color marker (trTCM), that compares incomingbursts to Bc and Be and decides on the color to be assigned: conforming (green, under Bc), exceeding(yellow, under Be) or violating (red, over Be). Traffic bursts that exceed Bc will have their marking changed tosignalized higher drop precedence. The values for Bc and Be should be selected to be no less than RTT*CIRand RTT*PIR respectively, to allow for efficient TCP performance end-to-end. Here is how a two-rate three

color marker implementation would look like if using a token-bucket model:

As compared to a single-rate model, this one uses two separate flow of tokens filling the CBS (Bc) and EBS(Be) buckets. Overflowing tokens are simply spilled an not stored everywhere, there is no “fairness”mechanism in trTCM. Every incoming packet is compared to the amount of tokens in CBS and EBS, but thistime it results in comparing the traffic flow to separate pre-defined rates.

Handling Exceeding Packets in SP Network

The dual-rate contracts result in two interesting problems. Firstly, the exceeding packets should be handleddifferently in the SP network. Secondly, congestion needs to be signaled to the customer reaction point. Let’sstart with the packet burst that were marked as exceeding on the reception from the customer. Under

http://blog.ine.com/wp-content/uploads/2011/05/trTCM.png


4/12

congestion, those packets should have more chances of being dropped, as compared to “conforming”packets. This behavior could be implemented in two different ways:

Assigning the packets into separate queues, e.g. assign them to a best-effort queue. While this lookslogical, it may result in packet reordering. Imagine a TCP flow going between customer site, consumingmaximum allowed bandwidth (PIR). Some of the packet burst in this connection may actually conform toCIR, while others may be marked as exceeding. As a result, flow packets may be ordered even under moderate congestion in the network. In result, this will affect TCP performance as packet reordering maytrigger TCP Congestion Avoidance process, resulting in less than possible TCP sending rate. The

problem is that TCP cannot reliable tell if packet reordering is a result of packet drop or networkqueueing. Assigning the packets to a lower drop threshold in the same queue as the conforming traffic. This could

be implemented in many different ways, e.g. using different WRED thresholds for different DSCP valuesor having different drop limit for DE-marked Frame-Relay packets. Using this method will reduce chancesof packet re-ordering but may increase end-to-end delay for all traffic. Due to the serious impact of packetre-ordering on TCP congestion avoidance mechanism, using this method is the recommended treatment.

Signaling a network congestion might be difficult in some networks. Not every packet switching technologysupports this feature, and many of them may support different signaling. In the most simple case, there is noexplicit congestion signaling, like in IP networks (ignoring the obsolete ICMP source quench message). In thiscase, upper-level protocol is supposed to recognize quality degradation and respond by slowing sending rate.

This is automatically done by the commonly used TCP protocol. As another example, you may consider theuse of RTP and RTCP protocols, where RTCP is used to control call quality and may change codecs inresponse to network condition degradation. Consider Frame-Relay next – congestion may be signaled usingBECN bit to signal traffic source to slow down its sending rate. Notice that in Frame-Relay there are no further hints about congestion, e.g. no indication on how far the sender should go down, so the reaction point mayonly implement a pre-programmed response. There are numerous other implementation of explicit congestionnotification, such as ones used in ATM or Data-Center bridging, or more well-known TCP ECN. Those,however, are out of the scope of this blog post. We will mainly consider the Frame-Relay BECNs and in-builtTCP congestion response.

What is the difference between Tc in traffic shaping in policing

The value of Tc is often used in traffic shaping calculating. However, the meaning and the use of the shapingtime interval is different from policing Tc. When traffic is metered, Tc defines the length of sliding window over a time axis that is effectively used to find the average traffic rate. With traffic shaping, Tc defines the periodicscheduling interval to be used when emitting traffic bursts by the shaper’s leaky bucket algorithm. When youmatch shaping settings against the ingress policing, you need to make sure that shaping Tc does not exceedthe configured policing Tc – otherwise, the shaper may produce bursts that are always rejected by the policer.The same logic applies to the Be burst values used in traffic shaping and policing. There is a substantialdifference in Cisco IOS implementation. For traffic shaping, sBc+sBe is the maximum amount of bits you cansend during a single interval. This cumulative burst will be compared to either policing pBc value or policingpBe value independently, when using ingress MQC policing. Therefore, you need to make sure thatpBe>=sBc+sBe, or the excessive burst may be rejected by the policer. Finally, notice that if shaping Be is setto a value above (AR-CIR)*Tc it will take more than single Tc interval to schedule sending of excessive traffic.

Effectively, during a single Tc interval a shaper cannot send more than AR*Tc bits, which means themaximum excessive burst value is (AR-CIR)*Tc during a single Tc. Setting Be over this value will result inexcessive bursting split across multiple scheduling intervals.

Implementing Single Rate Traffic Contracts in Cisco IOS

We’ll be using Frame-Relay as the SP access technology for our examples. Let’s assume that we have atraffic contract for CIR=256Kbps and a normal burst size of Bc=25600 bits. The contract should beimplemented on a T1 connection with a bit-rate of 1544000 bps. These values translate in policing averaginginterval of Tc=25600/256000=100ms (1/10 of second). The contact needs to be enforced on customer sideusing traffic shaping with a Tc value


5/12

Be=Bc=25600 bits.

Policing:

CIR=256000 bpsBc=3200 bytesBe=6400 bytes (to allow admission of shaping Bc+Be)

Look at how this policy could be implemented on customer side using legacy Frame-Relay Traffic Shaping:

map‐class frame‐relay SHAPE_256K

frame‐relay cir 256000frame‐relay bc 25600frame‐relay be 25600frame‐relay mincir 256000

!interface Serial 0/0/0

frame‐relay traffic‐shaping!interface Serial 0/0/0.1

frame‐relay interface‐dlci 101class SHAPE_256K

Notice that we set MinCIR value in the FRTS map-class to the same value as CIR to ensure that potentialQoS policy would use proper absolute bandwidth values. Here is how an ingress SP policy would look like if

MQC traffic policing is used:

class‐map DLCI_101match fr‐dlci 101

!policy‐map POLICE_INTERFACE

class DLCI_101police cir 256000 bc 3200 be 6400

conform‐action transmit exceed‐action set‐frde‐transmit

violate‐action drop!interface Serial 0/0/0

service‐policy input POLICE_INTERACE

Notice the use of MQC syntax and class-map matching FR DLCI. Cisco IOS supports feature known asFrame-Relay Traffic Policing (FRTP) that could be used to implement the same functions using the "legacy"map-class syntax, but the use of MQC is more common nowadays. How would the shaping implementationlook if we were using MQC for traffic shaping?

policy‐map SHAPE_256Kclass class‐default

shape average 256000 25600 25600!map‐class frame‐relay SHAPE_256K

service‐policy output SHAPE_256K!interface Serial 0/0/0.1


If you are looking for more information on FRTS flavors, take a look at the following blog post: The four flavorsof Frame-Relay Traffic Shaping

Implementing Dual-Rate Traffic Contracts in Cisco IOS

Let's take the traffic contract from previous example with CIR=256Kbps and AR=1544Kbps and normal burstsize of 25600 bits. Next, add PIR=512Kbps to these values along with Be=51200. Make a quick list of shaping/policing values:

Shaping:

minCIR=256000 bpsCIR=512000 bpsBc=51200 bitsBe=0 bits.

http://blog.ine.com/2010/06/14/the-four-flavors-of-frame-relay-traffic-shaping/


6/12

Policing:

CIR=256000 bpsPIR=512000 bpsBc=3200 bytesBe=6400 bytes

Pay special attention to the shaping parameters. First of all, Be=0, which means sporadic sending of excessive traffic bursts is disabled. Secondly, the CIR is set to 512Kbps, or in other words to the SP's PeakRate. This means the customer is allowed to send at the rate of 512Kbps at any time. The minCIR is set to

256Kbps, meaning the customer will throttle down to contracted CIR upon reception of BECNs (if configured).The Bc size corresponds to the policing Be size - in case of congestion, the shaper willautomatically shrink the burst size down to the value matching the CIR. Here is how a legacy FRTSconfiguration would look on customer side:

map‐class frame‐relay SHAPE_256Kframe‐relay cir 512000frame‐relay bc 51200frame‐relay be 0frame‐relay mincir 256000

frame‐relay adaptive‐shaping becn!interface Serial 0/0/0

frame‐relay traffic‐shaping

!interface Serial 0/0/0.1frame‐relay interface‐dlci 101

class SHAPE_256K

Once again, notice that shaping CIR equals the SP's PIR and shaping minCIR corresponds to the actual SPCIR. Also notice that adaptive-shaping is now enabled under the map-class to allow dynamic response toBECN messages. The SP-side configuration would look as following, using MQC syntax:

class‐map DLCI_101match fr‐dlci 101

!policy‐map POLICE_INTERFACE

class DLCI_101

police cir 256000 bc 3200 pir 512000 be 6400conform‐action transmit

exceed‐action set‐frde‐transmitviolate‐action drop

!interface Serial 0/0/0

service‐policy input POLICE_INTERACE

Which looks very similar to the single-rate example, just now PIR is explicitly configured. Finally, let's see howthe shaping configuration would look like when using MQC syntax:


shape average 512000 51200 0

shape adaptive 256000!map‐class frame‐relay SHAPE_256K

service‐policy output SHAPE_256K!interface Serial 0/0/0.1


Notice the use of adaptive shaping in MQC syntax. This command will only work if you apply shaping usingthe map-class model, and won't work if you simply apply a policy to interface. It is also possible to re-write theshaping configuration using the "shape peak" command (see more about this command in the blog post titledUnderstanding the "shape peak" command :


shape peak 256000 25600 25600shape adaptive 256000

!map‐class frame‐relay SHAPE_256K

service‐policy output SHAPE_256K

http://blog.ine.com/2008/08/26/understanding-the-shape-peak-command/


7/12

!

interface Serial 0/0/0.1frame‐relay interface‐dlci 101

class SHAPE_256K

Using this syntax allows for clearly showing the Bc and Be portions of the traffic contract, even though theresult will be the same as if using the "shape average" command.

Summary

This blog post illustrated the two most commonly used types of traffic contracts in their basic forms andexplained the concepts of various bursts used in the specification. Furthermore, there are some examples of enforcing the traffic contracts on both customer and SP sides.

Tags: ccie qos, frame-relay traffic shaping , srTCM, traffic contract, traffic policing, trTCM

Download this page as a PDF

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed intonetworking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University'scampus network support and UNIX system administration, he went through the path of becoming a networkingconsultant, taking part in many network deployment projects. Petr currently has over 12 years of experienceworking 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 manyyears. 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 c an leav e a res pons e, or trac k bac k from y our own s ite.

21 Responses to “Understanding Single-Rate and Dual-Rate Traffic Policing”

1. Ash says:

May 22, 2011 at 6:22 am

Perfect!!!

Reply

2. Ash says:May 22, 2011 at 6:23 am

Was extremely helpful.

Reply

3. TiFFolk says:May 22, 2011 at 6:54 am

Nice topic, Petr! Happy to see new tech posts on this blog

Do you have any plans to continue BGP topic? As you said:

http://-/?-http://-/?-http://-/?-http://-/?-http://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?replytocom=293612#respondhttp://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?replytocom=293611#respondhttp://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/trackback/http://blog.ine.com/?author=5http://blog.ine.com/?author=5http://pdfcrowd.com/url_to_pdf/?height=-1http://blog.ine.com/tag/trtcm/http://blog.ine.com/tag/traffic-policing/http://blog.ine.com/tag/traffic-contract/http://blog.ine.com/tag/srtcm/http://blog.ine.com/tag/frame-relay-traffic-shaping/http://blog.ine.com/tag/ccie-qos/


8/12

“Wedidn’t not concentrate on the detailed mechanics of BGP fast peering session deactivation e.g. for multihopsessions and we did not cover the MPBGP specific features. Some MP -BGP extensions such as the additionalimport scan interval and edge control plane interworking have their effects on endto-end convergence, but this isa topic for another discussion.”

Reply

Petr Lapukhov, 4xCCIE/CCDE says:May 22, 2011 at 9:38 am

Absolutely, I’m working on a post dedicated to BGP mesh designs and fast convergence

Reply

4. Wayne says:May 22, 2011 at 7:18 am

Petr,

In trTCM you have S1 and S2, and S. Can you please clarify their definition?

Reply


Wayne, S1 and S2 are the amounts of tokens added to each bucket during every replenish intervalTi. Ideally, a single token should be added every 1/CIR ms interval to CBS bucket, but it’s notpossible to set hardware time support any resolution for token bucket algorithm. Therefore, the tokenbucket scheduler normally runs every Ti ms and CIR*Ti tokens are added to CBS bucket whilePIR*Ti to the EBS bucket (for dual-rate policing). It is also possible to implement token bucket

differently, but using fixed timer ensures that computation complexity is kept the same, regardless of the packet rate.

Reply

5. Deepak Arora says:May 22, 2011 at 10:46 pm

Any plans for redoing CCIP QOS class or doing a new CCIE QOS Deev Dive class?

Reply

Brian McGahan, CCIE #8593 says:May 23, 2011 at 9:08 am

@Deepak Yes to both.

Reply

6. Matt says:May 24, 2011 at 7:01 am

Hi Petr,

Nice article, however there is one thing that is not clear to me: in the case of the “Single Rate TrafficContracts”, why should the pBe equals sBc+sBe ? You wrote above that during a Tc, the policer will letthrough pBc+pBe so I am confused as to why pBe cant be equal to just sBe ?

Thanks,Matt

http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-http://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?replytocom=294294#respondhttp://www.ine.com/http://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?replytocom=294063#respondhttp://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?replytocom=293674#respondhttp://blog.ine.com/?author=5http://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?replytocom=293634#respondhttp://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?replytocom=293672#respondhttp://blog.ine.com/?author=5http://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?replytocom=293623#respond


9/12

Reply

Petr Lapukhov, 4xCCIE/CCDE says:May 24, 2011 at 12:13 pm

Matt, I think I might have made a mistake there. At any given time, the policer compares currentburst with *either* Bc *or* Be – that’s what displayed on the diagram. Therefore, the policer Beshould be at least as large as the total amount of bit emitted by the shaper, which could be as highas sBc + sBe (or, to be more accurate, it’s as much as AR*Tc).

Reply

Matt says:May 25, 2011 at 1:48 am

Well, looking at the formula in the diagram (and racking my brain on it!), as long as CBS is bigenough, then we aren’t going to decrement EBS. Only once CBS is too low will we decrementEBS. So we are really going to let through CBS+EBS, no ?

Looking at cisco’s documentation that also the way I understand it.

http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_n1.html#wp1060117

Reply

Turgay says:June 9, 2011 at 9:50 pm

Thank You for reply on my previous question.But I have the same question as Matt. I agree that policer Be should be above or equal then sBc+ sBe in the case of dual-rate contract. But in my opinion this is true for single-rate only if weconsider the burst as indivisible. If the burst consists of several frames policer sBe should beabove or equal sBe.

Reply

7. Turgay says:May 26, 2011 at 11:28 pm

Hello Petr,I don’t understand one issue with policing and shaping.What a Cisco device would do if it receives packet whose size is greater than allowed burst? For example,CIR = 128000 bpsBc = 1280 bits = 160 bytesBe = 0

If shaper needs send a packet of 1500 bytes it will never accumulate required quantity of tokens. So thepacket isn’t schedule from queue forever.

Reply


In short, the shaper/policer burst should always be above maximum packet size. Normally, this isbased on common MTU, but keep in mind that IP packet could be as large as 64Kbytes,theoretically. While shaper will still emit packets even if the Bc < MTU (there are certainapproximations) the policer will not admit a single packet if the Bc < MTU.

Reply

8. Al says:February 21, 2012 at 5:44 am

http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-http://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?replytocom=298201#respondhttp://blog.ine.com/?author=5http://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?replytocom=297834#respondhttp://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?replytocom=311203#respondhttp://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?replytocom=295522#respondhttp://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_n1.html#wp1060117http://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?replytocom=295128#respondhttp://blog.ine.com/?author=5http://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?replytocom=294947#respond


10/12

With regards to dual-rate 3 color policers, I don’t understand the below:

“The values for Bc and Be should be selected to be no less than RTT*CIR and RTT*PIR respectively, toallow for efficient TCP performance end-to-end. ”

What is the consequence of having Bc < RTT*CIR ?

Also, great article, thank you!

Regards,

Al

Reply

9. Babak says:March 18, 2012 at 11:15 am

Sorry another question just popped up and I think this is because I am trying to grasp the concept sohard. This is a very basic question that stems from my confusion:

The concept behind policing is to keep the bit rate at an average constant and drop or remark the excess.

Now if we want to configure a police rate of for example 64Kbps, we definetly have to specify the Bc inorder to reach that rate. Am I correct? In other words, we need to specify the Bc to be 1 second worth of traffic converted to bytes or 64000/8=8000 Bytes. Is this correct?

Now what happens when we do not specify the Bc in the police command? I assume that the IOS defaultis to set the Bc to one forth of the police rate. For example if police rate = 64000 Kbps then the IOSdefault is to set the BC according to the following formula:BC default = 64000/(4*8)=2000 BytesDoes this mean that our actual police rate is 64000/4=16 Kbps?

Thanks again for answering these questions.

Reply

Vinoth Kumar says:February 20, 2013 at 8:41 pm

@Babak,

I had a similar question. Did you find any answers for the one you posted last year. I have acustomer for whom we have configured 8Mbps on the PE as ingress policer. They left the decisionon IOS and it selected a bc as 250000 which is 2Mega Bits per interval with 4 intervals for 1 second.

Now my question is if the IOS would work to reach 8Mbps over one second or would havechallenges.

Vinoth

Reply

10. Thomas says:November 21, 2012 at 3:33 pm

You seem to have a typo in one of the diagrams. It says “Size1=Size1-S”. I think you mean “EBS=EBS-S”.

I blogged about this back in January of 2010 because the Internet seemed to be missing articles about

that were actually *accurate*:

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

Your blog post here seems to also add sanity to the field of QoS, but I expect nothing less from you Petr.

http://-/?-http://-/?-http://-/?-http://blog.habets.pp.se/2010/01/Shaping-and-policing-on-Ciscohttp://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?replytocom=486905#respondhttp://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?replytocom=478165#respondhttp://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?replytocom=477408#respond


11/12

Reply

11. Andres Cervantes says:May 22, 2013 at 9:58 am

I have not been able to undestood why using the new MQC model Be changes from 25600bits to6400bytes.

Be=6400 bytes (to allow admission of shaping Bc+Be)

How did you came up with this mumber please explain me.

Reply

12. Andres Cervantes says:May 22, 2013 at 10:12 am

From what I understood the Be bucket get fill with tokens that overflow the BC bucket , then if I do nothave information to send during a Tc at my next Tc I will be able to spill the tokens to the Be bucket butfrom your example Be its only 6400 bytes then I will never be able to recover one Tc that as for theexample the provider agree to compensate for idle times.

Then Be should be equal to Bc even if you use the new format that is the only way I will be able torecovery a full time slot after idle time.

Reply

13. Jey says:May 28, 2013 at 9:21 am

Hi Petr

I do understand how shaping and policing works, however I am in doubt about something when given 2time intervals, lets say 400ms for CIR and Normal burst and then PIR Be time interval set to 200ms.

It is almost like task 10.26 in Workbook 1.

I understand the Be is calculated from the PIR value but also read that when you do a two-rate policer that it equals 2 * Bc.

Could you explain this ?

Reply

Leave a Reply

Nam e (required)

M ail (will not be publis hed) (required)

Submit Comment

Search

Search Submit

http://-/?-http://-/?-http://-/?-http://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?replytocom=494636#respondhttp://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?replytocom=494133#respondhttp://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?replytocom=494132#respondhttp://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?replytocom=484716#respond


12/12

Categories

Select Category

CCIE Bloggers

Brian Dennis, CCIEx5 #2210Routing & SwitchingVoice

SecurityService Provider ISP Dial

Brian McGahan, CCIEx4 #8593, CCDE #2013::13DesignData Center Routing & SwitchingSecurityService Provider

Mark Snow, CCIEx4 #14073Data Center Collaboration

SecurityVoice

Petr Lapukhov, CCIEx4 #16379, CCDE #2010::7DesignRouting & SwitchingSecurityService Provider Voice

Popular Posts

No posts to display

twitter.com/ineFollow

© 2011 INE, Inc ., All Rights Res erv ed
http://www.linkedin.com/companies/144650http://feeds.feedburner.com/ine/http://www.youtube.com/INEtraininghttp://www.facebook.com/inetraininghttp://twitter.com/inehttp://twitter.com/inehttp://twitter.com/inehttp://twitter.com/inehttp://www.ine.com/about-us.htm#mshttp://www.ine.com/about-us.htm#mshttp://www.ine.com/about-us.htm#bmhttp://www.ine.com/about-us.htm#bd

Documents

Understanding Single-Rate and Dual-Rate Traffic Policing