Many people have problems understanding the meaning of Bc (committed burst) used with traffic policing. Everyone seems to know the “magic” formula (Bc=1,5sec*CIR) but have a vague understanding of the reasons behind it. Let’s clear the confusion and see what Bc really affects when it comes to policing.
This finite time interval is called the averaging interval, as you only measure the average speed during the time span. You may have driven the first 50 miles in 15 minutes and the rest of the 50 miles in 45 minutes – but your average speed during one hour would still be 100Mps; even though it was an average of 200Mph during the first 15 minutes. It’s clear that a longer averaging interval allows for more speed variations within, while shorter intervals tend to measure the value closer to “instant speed”.
If you draw graphs of the speed measurement using different averaging intervals, you will quickly notice that the shorter intervals produce more oscillating, jerky graphs closer following the “instant” speed, while longer intervals result in smoothed graphs that lag in time behind the “instant” speed graph.
Based on this observation, we need larger averaging intervals for “bursty” flows, i.e. flows that tend to group packets in batches and space them with “silent” time intervals. Metaphorically, this corresponds to your car driving very fast and then very slow. One good example of a protocol with bursty traffic flows is TCP, as it sends all the packets it can send within the receiver window and waits for the TCP ACKs to open the sender window. This is especially noticeable with large RTT between the sender and receiver. For a single TCP flow, you may want to make sure the policer would admit a whole window of the outstanding packets, in order to avoid triggering the slow-start behavior if you drop the exceeding packets. The window size might be roughly calculated as RTT*CIR (if you assume the CIR be the maximum sender’s speed in situations where you limit the traffic rate using policing). If you take an average RTT of 1,5 seconds (that’s probably true for a very long network) you will get the “magic” formula from the above for Bc. However, in real life you may need to pick up the Bc value empirically, based on the actual application performance in situations where you use traffic policing to limit the traffic rate.
Averaging and Smoothing
Imagine you’re driving a car and want to find out your speed. In order to do this, you need to count the time (T) it takes you to pass the distance (S). The speed is then V=S/T – what a nice looking elementary school formula. So if you drove 100 miles in 1 hour your speed is 100 Mph. However, if you drove 50 miles in 30 minutes, your speed is the same 100 Mph. The only difference between the two measurements is the time interval used. Ideally, the only real value is your instant speed defined as the limit of S/T with T going to zero. However, this only works well in mathematics – in the real world, you always need a finite time interval to perform the measurement.This finite time interval is called the averaging interval, as you only measure the average speed during the time span. You may have driven the first 50 miles in 15 minutes and the rest of the 50 miles in 45 minutes – but your average speed during one hour would still be 100Mps; even though it was an average of 200Mph during the first 15 minutes. It’s clear that a longer averaging interval allows for more speed variations within, while shorter intervals tend to measure the value closer to “instant speed”.
If you draw graphs of the speed measurement using different averaging intervals, you will quickly notice that the shorter intervals produce more oscillating, jerky graphs closer following the “instant” speed, while longer intervals result in smoothed graphs that lag in time behind the “instant” speed graph.
Traffic Policing and Averaging
The same averaging concept applies to traffic policing. The sole purpose of policing is comparing the average metered traffic rate with the CIR (committed information rate) and marking the packets that exceed it. The metering is essentially performed over the averaging interval Tc=Bc/CIR, where CIR is the metering rate. Therefore, the larger your Bc settings, the longer is the averaging time interval and the smoother is your speed measurement, allowing for speed oscillation within the time interval. So what’s better – a smaller Tc or bigger Tc? There is no answer, as they both measure the traffic rate correctly, just the bigger value allow for a more “unstable” traffic rate.Flow Burstiness
Look at the figure below. Let’s say we set the policer to allow one packet per interval T. Then, the second packet of the RED flow will be rejected. However, if we set the policer to permit 2 packets in 2xT interval, both RED and GREEN flows will be admitted. In both cases, the CIR is the same.Based on this observation, we need larger averaging intervals for “bursty” flows, i.e. flows that tend to group packets in batches and space them with “silent” time intervals. Metaphorically, this corresponds to your car driving very fast and then very slow. One good example of a protocol with bursty traffic flows is TCP, as it sends all the packets it can send within the receiver window and waits for the TCP ACKs to open the sender window. This is especially noticeable with large RTT between the sender and receiver. For a single TCP flow, you may want to make sure the policer would admit a whole window of the outstanding packets, in order to avoid triggering the slow-start behavior if you drop the exceeding packets. The window size might be roughly calculated as RTT*CIR (if you assume the CIR be the maximum sender’s speed in situations where you limit the traffic rate using policing). If you take an average RTT of 1,5 seconds (that’s probably true for a very long network) you will get the “magic” formula from the above for Bc. However, in real life you may need to pick up the Bc value empirically, based on the actual application performance in situations where you use traffic policing to limit the traffic rate.
0 comments:
Post a Comment