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 will 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 why you want to use shaping:
Your ISP sold you a fibre connection with a traffic contract and a guaranteed bandwidth of 10 Mbit, the fibre 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 (Commited 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 make sure everything will be sent.
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.
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 when we are pausing traffic. The first 62.5 ms we are sending traffic at 128 kbps and 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 that 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 a number of formulas that we can use to calculate the values above:
Bc value:
Bc = Tc * CIR
In 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 / CIR
We 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)
TC = 125 ms (the default)
125 ms x 128 kbps = 16.000 bits
So the Bc is 16.000 bits. 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 bitrate
Let’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 realtime traffic like VoIP so wasting 120 ms just waiting isn’t a very good idea. When you have realtime traffic like voice, Cisco recommends to set 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 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 it 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 less 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 awhile 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 article I will cover how to configure traffic shaping on a Cisco router. If you have any questions feel free to ask!
