Shaping is a QoS (Quality of Service) technique that we can use to enforce lower bitrates than what the physical interface is capable of. Most ISPs use shaping or policing to enforce “traffic contracts” with their customers. When we use shaping we will buffer the traffic to a certain bitrate, policing will drop the traffic when it exceeds a certain bitrate. Let’s discuss an example of why you want to use shaping:
Your ISP sold you a fiber connection with a traffic contract and a guaranteed bandwidth of 10 Mbit, the fiber interface however is capable of sending 100 Mbit per second. Most ISPs will configure policing to drop all traffic above 10 Mbit so that you can’t get more bandwidth than what you are paying for. It’s also possible that they shape it down to 10 Mbit, but shaping means they have to buffer data, while policing means they can just throw it away. The 10 Mbit that we pay for is called the CIR (Committed Information Rate).
There are two reasons why you might want to configure shaping:
- Instead of waiting for the policer of the ISP to drop your traffic, you might want to shape your outgoing traffic towards the ISP so that they don’t drop it.
- To prevent egress blocking. When you go from a high-speed interface to a low-speed interface you might get packet loss (tail drop) in your outgoing queue. We can use shaping to ensure everything will be sent (until its buffer is full).
In short, we configure shaping when we want to use a “lower bitrate” than what the physical interface is capable of.
Routers are only able to send bits at the physical clock rate. As network engineers, we think we can do pretty much anything, but it’s impossible to make an electrical or optical signal crawl slower through the cable just because we want to. If we want to get a lower bitrate, we will have to send some packets, pause for a moment, send some packets, pause for a moment…and so on.
For example, let’s say we have a serial link with a bandwidth of 128 kbps. Imagine we want to shape it to 64 kbps. If we want to achieve this we need to make sure that 50% of the time we are sending packets and 50% of the time we are pausing. 50% of 128 kbps = an effective CIR of 64 kbps.
For another example, let’s say we have the same 128 kbps link, but the CIR rate is 96 kbps. This means we will send 75% of the time and pause 25% of the time (96 / 128 = 0.75).
Now you have a basic idea of what shaping is, let’s take a look at a shaping example so I can explain some terminology:
Above, we see an interface with a physical bitrate of 128 kbps that has been configured to shape to 64 kbps. On the vertical line, you can see the physical bitrate of 128 kbps. Horizontally you can see the time from 0 to 1000 milliseconds. The green line indicates when we send traffic and pause traffic. For the first 62.5 ms we are sending traffic at 128 kbps and for the second 62.5 ms we are pausing. This first interval takes 125 ms (62.5 + 62.5 = 125 ms) and we call this interval the Tc (Time Interval).
In total, there are 8 time intervals of 125 ms each. 8x 125 ms = 1000 ms. Most Cisco routers have a Tc default value of 125 ms. With the example above, we are sending traffic 50% of the time and pausing 50% of the time. 50% of 128 kbps = shaping rate of 64 kbps.
Our Cisco router will calculate how many bits it can send each Tc so that it will reach the targetted shaping rate. This value is called the Bc (committed burst).
In the example above, the Bc is 8.000 bits. Each Tc (125 ms) it will send 8.000 bits, and when it’s done it will wait until the Tc expires. In total, we have 1.000 ms of time. When we divide 1.000 ms by 125 ms, we have 8 Tcs. 8000 bits x 8 Tcs = shaping rate of 64 kbps.
To sum things up, this is what you have learned so far:
- Tc (time interval) is the time in milliseconds over which we can send the Bc (committed burst).
- Bc (committed burst) is the amount of traffic we can send during the Tc (time interval) and is measured in bits.
- CIR (committed information rate) is the bitrate that is defined in the “traffic contract” that we received from the ISP.
There are several formulas that we can use to calculate the values above:
Bc value:
Bc = Tc * CIRIn the example above, we have a Tc of 125 ms, and we are shaping to 64 kbps (that’s the CIR), so the formula will be:
125 ms * 64 kbps = 8.000 bits.
Tc value:
Tc = Bc / CIRWe just calculated the Bc (8.000 bits), and the CIR rate is 64 kbps. The formula will be:
8.000 bits / 64.000 = 0.125. So that’s 125 ms.
Let’s look at another example. Imagine we have an interface with a physical bitrate of 256 kbps, and we are shaping to 128 kbps. How many bits will we send each Tc?
CIR = 128 kbps
TC = 125 ms (the default)
125 ms x 128 kbps = 16.000 bits
So the Bc is 16.000 bits. For each Tc, we will send 16.000 bits.
The shaper will grab 16.000 bits each Tc and send them. Once they are sent, it will wait until the Tc has expired, and a new Tc will start.
The cool thing about shaping is that all traffic will be sent since we are buffering it. The downside of buffering traffic is that it introduces delay and jitter. Let me show you an example:
Above we have the same interface with a physical bitrate of 128 kbps and the Tc is 125 ms. Shaping has been configured for 64 kbps. You can see that each Tc it takes 62 ms to send the Bc. How did I come up with this number? Let me walk you through it:
125 ms * 64 kbps = 8.000 bits.
Now we know the Bc, we can calculate how long it takes for a 128 kbps interface to send these 8000 bits. This is how you do it:
Delay value:
Delay = Bc / physical bitrateLet’s try this formula to find out how long it takes for our 128kbps interface to send 8.000 bits:
8.000 / 128.000 = 0.0625
So it takes 62.5 ms to send 8000 bits through a 128 kbps interface. If we have a fast interface, the delay will, of course be a lot lower. Let’s say we have a T1 interface (1.54 Mbit):
8.000 / 1.540.000 = 0.0051
It only takes 5 ms to send 8000 bits through a T1 interface.
The default Tc of 125 ms is maybe not a very good idea when you are working with Voice over IP. Imagine that we are sending a data packet that is exactly 8.000 bits over this T1 link. It will only take 5 ms, but that means that we are waiting 120 ms ( 125 ms – 5 ms) before the Tc expires, and we can send the next 8.000 bits. If this next packet is a VoIP packet, then it will at least be delayed by 120 ms.
Cisco recommends a one-way delay of 150 to 200 ms for real-time traffic like VoIP, so wasting 120 ms just waiting isn’t a very good idea. When you have real-time traffic like voice, Cisco recommends setting your Tc to 10ms to keep the delay to a minimum.
So if we set our Tc to 10 ms instead of the default 125 ms…what will our Bc be? In other words, how many bits can we send during the Tc of 10 ms?
Let’s get back to our 128 kbps interface that is configured to shape to 64 kbps to calculate this:
10 ms * 64 kbps = 640 bits.
640 bits is only 80 bytes…not a lot, right? Many IP packets are larger than 80 bytes, so if you configure the Tc at 10 ms, you will probably also have to use fragmentation. In this example, IP packets should be fragmented to 80 bytes each.
How are you doing so far? I can imagine all the terminology and formulas make your head spin. We are almost at the end. We only have to talk about the excess burst.
When we configure traffic shaping we have the option to send more than the Bc in some Tcs. There is a very good reason to do this. Data traffic is not smooth but very bursty…sometimes we don’t send anything, then a few packets, and suddenly there’s an avalanche of traffic. It would be nice if you can send a little bit more traffic than the normal ‘Bc’ after a quiet period. To illustrate this we first need to talk about the token bucket.
Imagine we have a bucket….this bucket we will fill with tokens, and each token represents 1 bit. When we want to send a packet, we will grab the number of tokens we require to send this packet. If the packet is 120 bits, we will grab 120 tokens and send the packet. The amount of tokens in this bucket is the Bc. Once the bucket is empty, we can’t send anything anymore, and you’ll have to wait for the next Tc. At the next Tc, we will refill our token bucket with the Bc, and we can send it again.
This means that we can never send more than the Bc…it’s impossible to save tokens so that you can go beyond the Bc. If we don’t use all of our tokens, they won’t fit in the bucket, and they will be discarded. When it comes to shaping, it’s good to be a big spender…use those tokens!
Now let’s talk about the excess burst. We still have the same token bucket, but now the bucket is larger and can contain the Bc + Be. At the beginning of the Tc, we will only fill the token bucket with the Bc, but because it’s larger, we can “save” tokens up to the Be level. The advantage of having a bigger bucket is that we can save tokens when we have periods of time where we send fewer bits than the configured shaping rate. Normally the bucket would spill once the Bc is full, but now we can save up to the Be level.
Let’s take a look at an example of a shaper that we configured to use the Bc and the Be:
Above, you see an interface with a physical bitrate of 128 kbps. It has been configured to shape to 64 kbps with a default Tc of 125 ms. This means the Bc is 8.000 bits, and the Be is configured at 8.000 bits. This means we can store up to 16.000 bits. Imagine that the interface didn’t send any traffic for quite some time. This allows the token bucket to fill up to 16.000 bits (8.000 Bc + 8.000 Be). This means that in the first 125 ms, we can send 16.000 bits.
In the second interval, the token bucket is refilled up to the Bc level so we can send another 8.000 bits. There’s quite some traffic, so each Tc all 8.000 Bc bits are used. After a while all traffic has been sent, which allows us to save tokens again and fill the token bucket completely up to the Bc+Be level. The usage of the Be allows us to effectively “burst” after a period of inactivity.
So there you go. You have now learned how traffic shaping works, what the CIR, Tc, Bc, and Be are, and how to calculate them. In another lesson, I will cover how to configure traffic shaping on a Cisco IOS router. If you have any questions feel free to ask!