Determining Proper Burst Size for Traffic Policers
Policer Burst Size Limit Overview
A policer burst-size limit controls the number of bytes of traffic that can pass unrestricted through a policed interface when a burst of traffic pushes the average transmit or receive rate above the configured bandwidth limit. The actual number of bytes of bursty traffic allowed to pass through a policed interface can vary from zero to the configured burst-size limit, depending on the overall traffic load.
By configuring a proper burst size, the effect of a lower shaped rate is alleviated. Use the burst-size-limit statement to configure the burst size.
If you set the burst-size limit too low, too many packets will be subjected to rate limiting. If you set the burst-size limit too high, too few packets will be rate-limited.
Consider these two main factors when determining the burst size to use:
The allowed duration of a blast of traffic on the line.
The burst size is large enough to handle the maximum transmission unit (MTU) size of the packets.
The following general guidelines apply to choosing a policer burst-size limit:
A burst-size limit should not be set lower than 10 times the MTU of the traffic on the interface to be policed.
The amount of time to allow a burst of traffic at the full line rate of a policed interface should not be lower than 5 ms.
The minimum and maximum values you can specify for a policer burst-size limit depends on the policer type (two-color or three-color).
The preferred method for choosing a burst-size limit is based on the line rate of the interface on which you apply the policer and the amount of time you want to allow a burst of traffic at the full line rate.
Effect of Burst-Size Limit
Bursty traffic requires a relatively large burst size so that extra tokens can be allocated into the token bucket for upcoming traffic to use.
- Bursty Traffic Policed Without a Burst-Size Limit
- Burst-Size Limit Configured to Match Bandwidth Limit and Flow Burstiness
- Burst-Size Limit That Depletes All Accumulated Tokens
Bursty Traffic Policed Without a Burst-Size Limit
Figure 1 shows an extreme case of bursty traffic where the opportunity to allocate tokens is missed, and the bandwidth goes unused because a large burst size is not configured.
Burst-Size Limit Configured to Match Bandwidth Limit and Flow Burstiness
Figure 2 depicts how bandwidth usage changes when a large burst size is configured to handle bursty traffic. The large burst size minimizes the amount of unused bandwidth because tokens are being allocated in between the bursts of traffic that can be used during traffic peaks. The burst size determines the depth of the token bucket.
Burst-Size Limit That Depletes All Accumulated Tokens
Configuring a large burst size for the unused tokens creates another issue. If the burst size is set to a very large value, the burst of traffic can be transmitted from the interface at line rate until all the accumulated tokens in the token bucket are used up. This means that configuring a large burst size can allow too many packets to avoid rate limiting, which can lead to a traffic rate that exceeds the bandwidth limit for an extended period of time.
If the average rate is considered within 1 second, the rate is still below the configured bandwidth limit. However, the downstream device might not be able to handle bursty traffic, so some packets might be dropped.
Two Methods for Calculating Burst-Size Limit
For policers configured on MX Series, M120, and M320 routers, and EX Series switches, configurable burst-size limit values range from 1 ms through 600 ms of traffic at the policer rate (the configured bandwidth limit).
Because one burst size is not suitable for every traffic pattern, select the best burst size for an interface by performing experimental configurations. For your first test configuration, select the burst-size limit by using one of the calculation methods described in the next two sections.
- Calculation Based on Interface Bandwidth and Allowable Burst Time
- Calculation Based on Interface Traffic MTU
Calculation Based on Interface Bandwidth and Allowable Burst Time
If the bandwidth of the policed interface is known, the preferred method for calculating the policer burst-size limit is based on the following values:
bandwidth—Line rate of the policed interface (in bps units)burst-period—Allowable traffic-burst time (5 ms or longer)
To calculate policer bandwidth in bytes:
bandwidth X burst-period / 8
Calculation Based on Interface Traffic MTU
If the bandwidth of the policed interface is unknown, calculate the policer burst-size limit based on the following value:
interface MTU—Maximum transmission unit (in bytes) for the policed interface.
To calculate policer bandwidth in bytes:
interface MTU Χ 10
Comparison of the Two Methods
Figure 3 illustrates the relationship between the policer rate (the configured bandwidth limit) and the effective burst-size limit for the two methods of calculating the best policer burst-size limit. For the method based on interface bandwidth and allowable burst time, the correlation is labeled 5 ms. For the method based on MTU size, the correlation is labeled 10 MTU.
For a policer burst-size limit calculated using the 5 ms method, the effective burst-size limit is proportional to the configured bandwidth limit. With a very low bandwidth limit, the effective burst-size limit might be so small that the policer rate-limits traffic more aggressively than desired. For example, a traffic “burst” consisting of two MTU-sized packets might be rate-limited. In this scenario, a policer burst-size limit calculated using the 10 MTU method appears to be a better choice.
- 10 x MTU Method for Selecting Initial Burst Size for Gigabit Ethernet with 100 Kbps Bandwidth
- 5 ms Method for Selecting Initial Burst Size for Gigabit Ethernet Interface with 200 Mbps Bandwidth
- 200 Mbps Bandwidth Limit, 5 ms Burst Duration
- 200 Mbps Bandwidth Limit, 600 ms Burst Duration
10 x MTU Method for Selecting Initial Burst Size for Gigabit Ethernet with 100 Kbps Bandwidth
The following sequence illustrates the use of the 10 x MTU method for selecting an initial burst size for test configurations for a Gigabit Ethernet interface configured with a 100 Kbps bandwidth limit:
If you configure a 100 ms burst-size limit, the maximum amount of traffic allowed to pass through the interface unrestricted is 1250 bytes, calculated as follows:
100,000 bps x 0.1 s 100 Kbps x 100 ms = ————————————————————— = 1250 bytes 8 bits per byte
In theory, a 10 x MTU burst size would allow up to 15,000 bytes to pass unrestricted. However, the maximum configurable burst-size limit for MX Series, M120, and M320 routers is 600 ms of the bandwidth limit. If you configure the maximum burst-size limit of 600 ms of the bandwidth limit, the maximum amount of traffic allowed to pass through the interface unrestricted is 7500 bytes, calculated as follows:
100,000 bps x 0.6 s 100 Kbps x 600 ms = ————————————————————— = 7500 bytes 8 bits per byte
On a Gigabit Ethernet interface, a configured burst-size limit of 600 ms creates a burst duration of 60 μs at Gigabit Ethernet line rate, calculated as follows:
7500 bytes 60,000 bits ———————————— = ——————————————————— = 0.00006 s = 60 μs 1 Gbps 1,000,000,000 bps
If the downstream device is unable to handle the amount of bursty traffic allowed using the initial burst size configuration, reduce the burst-size limit until you achieve acceptable results.
5 ms Method for Selecting Initial Burst Size for Gigabit Ethernet Interface with 200 Mbps Bandwidth
The following sequence illustrates the use of the 5 ms method for selecting an initial burst size for test configurations for a Gigabit Ethernet interface configured with a 200 Mbps bandwidth limit. This example calculation shows how a larger burst-size limit can affect the measured bandwidth rate.
If you configure a 5 ms burst-size limit, the maximum amount of traffic allowed to pass through the interface unrestricted is 125,000 bytes (approximately 83 1500-byte packets), calculated as follows:
200,000,000 bps x 0.005 s 200 Mbps x 5 ms = —————————————————————————— = 125,000 bytes 8 bits per byte
On a Gigabit Ethernet interface, a configured burst-size limit of 5 ms creates a burst duration of 1 ms at Gigabit Ethernet line rate, calculated as follows:
125,000 bytes 1,000,000 bits ——————————————— = ——————————————————— = 0.001 s = 1 ms 1 Gbps 1,000,000,000 bps
The average bandwidth rate in 1 second becomes 200 Mbps + 1 Mbps = 201 Mbps, which is a minimal increase over the configured bandwidth limit at 200 Mbps.
If you configure a 600 ms burst-size limit, the maximum amount of traffic allowed to pass through the interface unrestricted is 15 Mbytes (approximately 10,000 1500-byte packets), calculated as follows:
200,000,000 bps x 0.6 s 200 Mbps x 600 ms = ————————————————————————— = 15,000,000 bytes 8 bits per byte
On a Gigabit Ethernet interface, a configured burst-size limit of 600 ms creates a burst duration of 120 ms at Gigabit Ethernet line rate, calculated as follows:
15,000,000 bytes 120,000,000 bits —————————————— = ——————————————————— = 0.12 s = 120 ms 1 Gbps 1,000,000,000 bps
The average bandwidth rate in 1 second becomes 200 Mbps + 120 Mbps = 320 Mbps, which is much higher than the configured bandwidth limit at 200 Mbps.
200 Mbps Bandwidth Limit, 5 ms Burst Duration
If a 200 Mbps bandwidth limit is configured with a 5 ms burst size, the calculation becomes 200 Mbps x 5 ms = 125 Kbytes, which is approximately 83 1500-byte packets. If the 200 Mbps bandwidth limit is configured on a Gigabit Ethernet interface, the burst duration is 125000 bytes / 1 Gbps = 1 ms at the Gigabit Ethernet line rate.
200 Mbps Bandwidth Limit, 600 ms Burst Duration
If a large burst size is configured at 600 ms with the bandwidth limit configured at 200 Mbps, the calculation becomes 200 Mbps x 600 ms = 15 Mbytes. This creates a burst duration of 120 ms at the Gigabit Ethernet line rate. The average bandwidth rate in 1 second becomes 200 Mbps + 15 Mbytes = 320 Mbps, which is much higher than the configured bandwidth limit at 200 Mbps. This example shows that a larger burst size can affect the measured bandwidth rate.