This blog post reviews and compares two most common types of traffic contracts - single rate and dual-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 at some examples of IOS configuration.

What is Traffic Contract

Service-providers network topology typically follows core/aggregation model, where network core has meshed topology and aggregation layers use some variation of tree topology. This design results in bandwidth aggregation when flows converge toward the core. Therefore, to avoid network resource oversubscription, accurate admission 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 a packet network, there is no such thing as a constant traffic flow rate, as flows only exist "temporarily" when packets are transmitted. In packet networks, it is common for service providers to connect customer using a sub-rate connection. Sub-rate a connection that provides only a fraction of the maximum possible link bandwidth, e.g. 1Mbps on a 100Mbps connection.

Implementing sub-rate access requires special agreement between service provider and customer - a specification 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, but there 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 maximum transmission 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 send traffic into the network. Notice the term "average" as packets are still being sent at the line rate (AR), and the information rate is defined by averaging measurement over some time interval. Per the definition, CIR is assumed to be less than AR
• Committed Burst Size (Bc). This value defines the maximum amount of contiguous packets that a customer is allowed to send in a single "batch". Packet traffic is commonly bursty, e.g. TCP connection is normally "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 a contiguous block of "Bc" bytes, it must pause for some time before sending the next batch. This is normally implemented using traffic-shaping at customer side.
• Excessive Burst Size (Be). This is a non-mandatory parameter that could be used to improve admission control "fairness". Let's say a customer connection has been idle for some time, and then customer got new 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 to accumulate 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 still remains 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 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 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 one customer site to another. At the very least, the equation Bc >= CIR*RTT should hold, where RTT is the maximum round-trip time site-to-site, per the SLA. At this moment, it is worth reminding that QoS tools are used 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, then Be 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 utilization look 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 burst size) first and then continues to filling the Be bucket (EBS, excess burst size). The second bucket is only filled if there was enough idle time to let the first bucket fill up completely. Every arriving packet is first compared to CBS and then to the EBS to determine the next action. The "Ti" interval is the special periodic timer that is used 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 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 may effectively 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 the network, discard traffic that exceeds the committed rate more aggressively and signal the customer to slow down to the committed rate. This principle was first widely implemented in Frame-Relay networks, but could be easily replicated using any packet-switching technology. There are four main parameters in a dual-rate traffic 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 - the averaging interval - is implicitly defined as Tc=Bc/CIR.
• Peak Information Rate (PIR). Additional parameter - defines the maximum average sending rate for the customer. 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 is the maximum size of the packet burst that could be accepted to sustain the PIR rate. Effectively, Be defines 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 bursts are metered and compared to CIR and PIR rates simultaneously, using the corresponding Bc and Be burst sizes. 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 exceeds CIR, but remains under PIR (e.g. current burst is still under Be), the burst has marking changed, but still admitted into the network. Finally, if the burst exceeds PIR, it is typically being discarded. Dual-rate contracts are normally implemented using some sort of two-rate, three color marker (trTCM), that compares incoming bursts 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 to signalized higher drop precedence. The values for Bc and Be should be selected to be no less than RTT*CIR and 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 this time 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 handled differently in the SP network. Secondly, congestion needs to be signaled to the customer reaction point. Let's start with the packet burst that were marked as exceeding on the reception from the customer. Under 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 looks logical, it may result in packet reordering. Imagine a TCP flow going between customer site, consuming maximum allowed bandwidth (PIR). Some of the packet burst in this connection may actually conform to CIR, 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 may trigger 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 network queueing.
• 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 values or having different drop limit for DE-marked Frame-Relay packets. Using this method will reduce chances of packet re-ordering but may increase end-to-end delay for all traffic. Due to the serious impact of packet re-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 technology supports this feature, and many of them may support different signaling. In the most simple case, there is no explicit congestion signaling, like in IP networks (ignoring the obsolete ICMP source quench message). In this case, 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 the use of RTP and RTCP protocols, where RTCP is used to control call quality and may change codecs in response to network condition degradation. Consider Frame-Relay next - congestion may be signaled using BECN 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 may only implement a pre-programmed response. There are numerous other implementation of explicit congestion notification, 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-built TCP 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 shaping time 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 periodic scheduling interval to be used when emitting traffic bursts by the shaper's leaky bucket algorithm. When you match shaping settings against the ingress policing, you need to make sure that shaping Tc does not exceed the 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 substantial difference in Cisco IOS implementation. For traffic shaping, sBc+sBe is the maximum amount of bits you can send during a single interval. This cumulative burst will be compared to either policing pBc value or policing pBe value independently, when using ingress MQC policing. Therefore, you need to make sure that pBe>=sBc+sBe, or the excessive burst may be rejected by the policer. Finally, notice that if shaping Be is set to 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 the maximum excessive burst value is (AR-CIR)*Tc during a single Tc. Setting Be over this value will result in excessive 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 a traffic contract for CIR=256Kbps and a normal burst size of Bc=25600 bits. The contract should be implemented on a T1 connection with a bit-rate of 1544000 bps. These values translate in policing averaging interval of Tc=25600/256000=100ms (1/10 of second). The contact needs to be enforced on customer side using traffic shaping with a Tc value <= 100ms to be admitted by SP. Let's also assume that the SP agrees to allow excessive bursting to compensate for a single idle Tc interval. The final values becomes will look as following (notice that policing values are given in bytes, to match Cisco IOS syntax).

Shaping:
CIR=256000 bps

Bc=25600 bits

Be=Bc=25600 bits.
Policing:
CIR=256000 bps

Bc=3200 bytes

Be=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 256000

 frame-relay bc 25600

 frame-relay be 25600

 frame-relay mincir 256000

!

interface Serial 0/0/0

 frame-relay traffic-shaping

!

interface Serial 0/0/0.1

 frame-relay interface-dlci 101

  class SHAPE_256K

Notice that we set MinCIR value in the FRTS map-class to the same value as CIR to ensure that potential QoS 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_101

 match fr-dlci 101

!

policy-map POLICE_INTERFACE

 class DLCI_101

  police 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 as Frame-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 implementation look if we were using MQC for traffic shaping?

policy-map SHAPE_256K

 class class-default

   shape average 256000 25600 25600

!

map-class frame-relay SHAPE_256K

 service-policy output SHAPE_256K

!

interface Serial 0/0/0.1

 frame-relay interface-dlci 101

  class SHAPE_256K

If you are looking for more information on FRTS flavors, take a look at the following blog post: The four flavors of 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 burst size 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 bps

CIR=512000 bps

Bc=51200 bits

Be=0 bits.
Policing:
CIR=256000 bps

PIR=512000 bps

Bc=3200 bytes

Be=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 Peak Rate. 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 will automatically shrink the burst size down to the value matching the CIR. Here is how a legacy FRTS configuration would look on customer side:

map-class frame-relay SHAPE_256K

 frame-relay cir 512000

 frame-relay bc 51200

 frame-relay be 0

 frame-relay mincir 256000

 frame-relay adaptive-shaping becn

!

interface Serial 0/0/0

 frame-relay traffic-shaping

!

interface Serial 0/0/0.1

 frame-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 SP CIR. Also notice that adaptive-shaping is now enabled under the map-class to allow dynamic response to BECN messages. The SP-side configuration would look as following, using MQC syntax:

class-map DLCI_101

 match fr-dlci 101

!

policy-map POLICE_INTERFACE

 class DLCI_101

  police cir 256000 bc 3200 pir 512000 be 6400

   conform-action transmit

   exceed-action set-frde-transmit

   violate-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 how the shaping configuration would look like when using MQC syntax:

policy-map SHAPE_256K

 class class-default

   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

 frame-relay interface-dlci 101

  class SHAPE_256K

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

policy-map SHAPE_256K

 class class-default

   shape peak 256000 25600 25600

   shape adaptive 256000

!

map-class frame-relay SHAPE_256K

 service-policy output SHAPE_256K

!

interface Serial 0/0/0.1

 frame-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 the result 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 and explained 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.