Traffic Policing vs. Traffic Shaping

One of the ‘hot’ topics when studying about Quality of Service (QoS) is Traffic Policing versus Traffic Shaping. In this article, we will look at these QoS features individually, compare them, and also see how they are used in the real world.

Network Quality

There are four major factors that affect the quality of a network including:

• Bandwidth: The most familiar factor of a network is the bandwidth which is a measure of the capacity available on a network link i.e. the fatness of a link. It is usually measured in bits per second (bps).
• Delay: Also known as latency, delay deals with how long it takes for a packet to get from the sender to the receiver. Of course, the more the delay, the slower the network “seems”. Delay is usually measured in milliseconds (ms).
• Jitter: This is a measure of the variation in delay between packets. For example, if a packet takes 30ms to get from point A to point B (that is delay), and another packet takes 40ms to get from the same point A to point B, then the jitter is 10ms (i.e. 40ms – 30ms).
• Loss: As packets ‘fly’ through a network, some of them can get lost i.e. not get to their destination.

Note: Bandwidth is not necessarily the same thing as speed even though both terms are sometimes used interchangeably. You can read this article to learn more about the subtle difference.

To keep our discussion simple, we will look at how these factors affect two broad categories of networks – Local Area Networks (LANs) and Wide Area Networks (WANs):

• Devices on a LAN are usually in close proximity to each other while the devices that make up a WAN are typically in different geographical areas and more than a few kms apart. This means that you typically don’t have to worry about delay/jitter on a LAN but these factors must be considered on a WAN especially for delay-sensitive applications like Voice.
• A LAN is usually under the control of the organization and they can build the network to their liking usually at a lower cost than a WAN where they (usually) have to go through a 3rd-party service provider. This means that bandwidth is more readily available on a LAN (at lower cost) than over a WAN where you typically get what you pay for.

From these two points, it is clear that a WAN is more susceptible to being affected by these 4 factors than a LAN and that is why most discussions about improving the quality of a network focus on the WAN.

This brings us to the topic of Quality of Service (QoS). With QoS, the goal is to ensure that important applications (as defined by the user) get the best service on the network, usually at the expense of less important applications. For example, since voice does not handle delay well, any voice packet that arrives at the WAN edge should be sent first even if there were other packets that arrived before that voice packet.

Note: QoS can also be applied on a LAN especially for voice traffic. However, a small to medium-sized LAN that is properly built and not oversubscribed will usually not need QoS features.

Two QoS features that are usually applied at the WAN Edge are Traffic Policing and Traffic Shaping. We will now look at these topics individually.

Traffic Policing

One of the most important duties of the police is to maintain law and order. If you as a citizen abide (conform) to the rules, you usually have nothing to worry about. However, if you are found violating a rule, there is usually repercussion.

In the same way, Traffic Policing is about performing an action (typically transmit/pass) to packets that conform to a specified rate and performing another action (typically drop) to packets that violate that rate.

Now let’s take it a step further in technical understanding. When an organization goes to an ISP for say an Internet service, the ISP can deliver this service through several physical infrastructure including fiber, radio, VSAT, etc. Let us assume the ISP uses fiber in this case and the organization only wants to purchase a 5Mbps service. How does the ISP ensure that the organization only gets what they pay for (5Mbps) even though the physical fiber connection to the organization can support far more speed (e.g. 100Mbps)? This is one of the uses of Traffic Policing. The ISP will have a contract with the organization that says anything outside 5Mbps will be dropped, and this will be implemented using traffic policing on the ISP side.

From our example, we can highlight a few technical terms:

• The 5Mbps is known as the Committed Information Rate (CIR) which is the average speed that the ISP guarantees the client.
• The maximum rate that the physical medium (e.g. the fiber) can transmit at is known as the Access Rate (AR).
• There’s also something called the Committed Burst (Bc) which defines the amount of packets (usually in bytes) that can be sent as a group without causing any violations or exceeding the CIR.

Cisco’s implementation of Traffic Policing

To further understand how traffic policing works, let us consider how Cisco implements this feature on their devices. Cisco uses a token bucket metaphor for both traffic policing and shaping. From a high level, this is how it works:

• A token can be “spent” and can be thought of the right to send a certain amount of traffic. In traffic policing, one token represents one byte of traffic.
• Tokens are deposited into the bucket at a certain rate – we will discuss this rate later.
• When packets come in, the policier will check that there are enough tokens in the bucket to send that traffic.
• If there are enough tokens in the bucket to send the packet, then that packet conforms and is sent out. The appropriate number of tokens are taken out of the bucket. For example, if there are 1000 tokens in the bucket and a packet of 514 bytes comes in, that traffic conforms and is sent out. Also, 514 tokens are “spent” and removed from the bucket.
• If there aren’t enough tokens in the bucket, the packet exceeds and is usually dropped (or reclassified depending on the configuration). No tokens are taken from the bucket.
• The bucket can fill up e.g. more tokens than the bucket can hold. In this case, the extra tokens are either discarded or put in another bucket for excess buckets.

The rate at which tokens are replenished inside the bucket is based on the following formula:

Note: The reason you divide by 8 bits is to convert it to bytes since token (in policing) are measured in bytes.

Let’s take an example. Imagine that an ISP has an agreement of 16Kbps with their client and has said that the client can send 1500 bytes in a single burst. This means that we have the following:

• CIR = 16Kbps = 16000bps
• Bc = 1500 bytes.

Now, if a packet comes in at 514 bytes, since the bucket starts full with 1500 bytes, and the packet conforms, 514 tokens are taken out of the bucket. The bucket now has 986 tokens left (1500 – 514). If another packet arrives 150ms (i.e. 0.15sec) later, the bucket is replenished with:

This means that the bucket will now hold (986+300) tokens i.e. 1286 tokens. If that packet that arrived is less than or equal to 1286 bytes, then it conforms and it is sent out. However, if that packet is say 1300 bytes, it exceeds and the exceed action is taken (e.g. dropped).

Lab: Traffic Policing in GNS3

Let us implement this example in GNS3 and see what happens. The lab setup is as shown below:

The “HOST” is actually just a Cisco router with a changed symbol. We will implement Traffic Policing on the ISP_RTR and the configuration is as follows:

ip access-list extended CUST_ACL
permit ip 172.16.1.0 0.0.0.255 any
!
class-map match-all CUST_CMAP
 match access-group name CUST_ACL
!
policy-map CUST_PMAP
 class CUST_CMAP
  police cir 16000 bc 1500
!
interface FastEthernet0/0
 ip address 192.1.2.1 255.255.255.0
!
interface FastEthernet0/1
 ip address 192.0.2.1 255.255.255.0
 service-policy input CUST_PMAP
!
ip route 172.16.1.0 255.255.255.0 192.0.2.2
!

In the configuration above, traffic from 172.16.1.0/24 is matched in a class map called CUST_CMAP. A CIR of 16000 and Bc of 1500 is then applied to this class map under a policy map called CUST_PMAP. The policy map is then applied inbound the Fa0/1 interface.

We can view this configuration using the show policy-map command:

As you can see, the conform-action of “transmit” and the exceed-action of “drop” have been applied by default. We can also use the show policy-map interface command to view the status of our traffic policing:

Let’s test this. We will ping from the HOST to the SERVER. To see the policing in action, we will increase the ping packet size and also the number of ping packets.

As you can see, some packets were dropped. We can check the ISP_RTR to see why this happened:

Traffic Shaping

While traffic policing is about dropping or reclassifying packets, traffic shaping tries to make traffic conform to a certain rate by delaying the packets in a buffer and sending them out as “space” becomes available.

For example, if the ISP is using traffic policing to ensure that their client’s traffic does not go past 5Mbps, the client can use traffic shaping on their side to make sure that all their traffic conforms to the 5Mbps rate even before getting to the ISP. The reason to do this is that once excess traffic gets to the ISP, it will be dropped. Instead, it will be more beneficial to delay the packets on their side to avoid dropping.

Cisco’s implementation of Traffic Shaping

Similar to Traffic Policing, Traffic Shaping as implemented by Cisco also uses a token bucket metaphor as follows:

• A token can be “spent” and can be thought of the right to send a certain amount of traffic. In traffic shaping, one token represents one bit of traffic.
• Tokens are deposited into the bucket at a certain rate – we will discuss this rate later.
• When packets come in, the shaper will check that there are enough tokens in the bucket to send that traffic.
• If there are enough tokens in the bucket to send the packet, then that packet is sent out.
• If there aren’t enough tokens in the bucket, the packet will be delayed until there are enough tokens to send that traffic out.
• The bucket can fill up e.g. more tokens than the bucket can hold. In this case, the extra tokens are either discarded or put in another bucket for excess buckets.

When discussing traffic shaping, tokens are added at certain time intervals (Tc) using the formula:

However, the real question is, “How do you ensure a certain CIR by delaying packets?” For example, let’s say we have a 256Kbps physical interface. That interface will always send traffic at 256Kbps – you cannot physically slow down that rate. This means that over a period of 1 sec, a 256Kbps interface will theoretically send 256,000 bits of data.

So let’s assume you want to make sure that only 64Kbps is sent over that link. How can you make a 256Kbps interface send say 64,000 bits over a period of 1 second instead? What you can do is break 1 second down into intervals (Tc) and only send a certain number of bits during each interval.

For example, if our time interval is 125 msec, it means we are dividing 1 second into 8 parts. To be able to send 64,000 bits over 1 second using 8 intervals, it means we must send 8,000 bits every interval (i.e. 64,000 / 8 = 8,000).

However, since the interface can physically send 32,000 bits every 125 msec (i.e. 256,000/8), it means that to achieve 8,000 bits per interval, we must only send at Access rate for 31.25 msec every interval i.e. [(8,000/32,000) * 125 msec].

From this example, 8,000 bits is our Bc required to maintain a CIR of 64Kbps over a period of 1 second, at 125 msec time interval. We can also calculate Bc using that formula above i.e. Bc = Tc * CIR.

Note: Remember that while Tc is usually expressed in msec, when used in that calculation, it is converted to seconds. For example, 125 msec is 0.125 second.

So in the case of traffic shaping and using our example, if a packet of 514 bytes (which is 4112 bits) arrives at time 0sec, it will be sent without any delay because there are enough tokens (8000 bits) in the bucket. However, if another 514 bytes packet arrives within the same time interval, that packet will be delayed until the next interval.

One more term we will talk about before going back to our lab is the Excess Burst (Be). Basically, it’s the ability to store up tokens that you did not use during a time interval. For example, if I didn’t send any packet during the 250ms time interval, I can send up to (Bc + Be) during the next interval:

Lab: Traffic Shaping in GNS3

Using the same lab as in traffic policing above, let us configure traffic shaping on all traffic leaving EDGE_RTR to conform to the 16Kbps CIR and a Bc of 1500 bytes (or 12,000 bits):

policy-map SHAPE_PMAP
 class class-default
  shape average 16000 12000 0
!
interface FastEthernet0/0
 ip address 172.16.1.1 255.255.255.0
!
interface FastEthernet0/1
 ip address 192.0.2.2 255.255.255.0
 service-policy output SHAPE_PMAP
!
ip route 192.1.2.0 255.255.255.0 192.0.2.1
!

In this case, I have used the default class map called “class-default” that matches all traffic that is not explicitly matched by another class map. Also noticed that I have applied the policy map in the outbound direction. On Cisco devices, traffic shaping can only be applied outbound. Finally, I have explicitly configured the CIR, Bc, and Be values. However, if you only specify the CIR, the Cisco software will automatically calculate the Bc and Be values.

We can view our configuration using the show policy-map command:

We can also view the status of our traffic shaping using the show policy-map interface command:

As you can see, some packets have already been matched because we are using the class-default class map. Let’s now initiate our ping from HOST to SERVER:

Compared to the result for traffic policing (84% success rate), we have a better success rate here. However, also notice that the average round-trip time has gone up to 230ms from 136ms when we did it with traffic policing. This tells us that some packets are being delayed. We can confirm this using the show policy-map interface command:

Note: In this case, we still lost packets. A better alternative will be to use a CIR less than (e.g. 80-85%) of the one the ISP is using so that shaping takes place before it hits that CIR. By changing my CIR to 12800 (80% of 16000) and keeping my Bc at 12000, I was able to get 100% success rate.

In our labs so far, we have not used the Be value. If you want to enable this value, there are certain things to keep in mind:

• If you enable Be on your traffic shaping policy, you need to make sure that it is also enabled on the traffic policing side.
• The maximum bit size that can be sent during one time interval in traffic shaping is Bc+Be.
• On the traffic policing side, every packet will be compared to either the Bc value (conformed) or Be value (exceeded). This means that the Be you configure on the traffic policing side must be at least equal to the Bc+Be value you configured on the traffic shaping side.
• By enabling Be, you now have three states a packet can be in: conformed (<=Bc), exceeded (<=Be), violated (>Be). You can configure an action for each state e.g. transmit, reclassify+transmit, drop.

So for example, if we have the following traffic shaping policy:

• CIR = 16000bps
• Bc = 12000 bits
• Be = 12000 bits

Then the corresponding traffic policing policy will be (or cannot be less than):

• CIR = 16000bps
• Bc = 1500 bytes (i.e. 12000 bits/8)
• Be = 3000 bytes (i.e. shaping Bc+Be)

Let us change the configuration on our devices to match these settings. On EDGE_RTR, the new policy map will be:

policy-map SHAPE_PMAP
 class class-default
  shape average 16000 12000 12000
!

On ISP_RTR, the configuration becomes:

policy-map CUST_PMAP
 class CUST_CMAP
  police cir 16000 bc 1500 be 3000
   conform-action transmit
   exceed-action set-dscp-transmit default
   violate-action drop
!

For the policing, we are transmitting packets that conform, transmitting packets that exceed but reclassifying them to a lower DSCP value (Best Effort), and dropping all packets that violate.

With this new configuration, let us test again by pinging from HOST to SERVER:

We can check the output of the show policy-map interface command on both EDGE_RTR and ISP_RTR:

As you can see, even though some of those packets exceeded, they were still transmitted without issues. You can play around with higher ping packet sizes till you find the one that causes a violation.

Conclusion

This brings us to the end of this article where we have looked at two QoS features that are often used in a complementary manner. While traffic policing is usually used to enforce a hard rate limit, traffic shaping is used to conform to that rate limit by delaying packets in a buffer.