JUNOSe 7.2.x Policy Management Configuration Guide
90 ! One-Rate Rate-Limit Profiles
The configuration values for the preceding attributes determine the degree of
friendliness of the rate-limit process. Instead of tail dropping packets that arrive
outside the committed and burst rate envelope, the TCP-friendly bucket enables
more tokens to be borrowed, up to a limit determined by the excess burst size. The
next packet that borrows tokens in excess of the excess burst size is deemed
excessive and is dropped if the exceeded action is set to drop.
The rate-limit algorithm is designed to avoid consecutive packet drops in the initial
stages of congestion when the packet flow rate exceeds the committed rate of the
token bucket. The intention is that just a few packet drops are sufficient for TCP’s
congestion control algorithm to drastically scale back its sending rate. Eventually,
the packet flow rate falls below the committed rate, which enables the token bucket
to replenish faster because of the reduced load.
If the packet flow rate exceeds the committed rate for an extended period of time,
the rate-limit algorithm tends toward hard tail dropping. In a properly configured
scenario, the rate limiter is consistently driven to borrow tokens because of TCP’s
aggressive nature, but it replenishes the tokens as TCP backs off, resulting in a
delivered rate that is very close to the rate configured in the rate-limit profile.
The recommended burst sizes for TCP-friendly behavior are:
! Committed burst—0.2 to 2.0 seconds of the committed rate
! Excess burst—1.0 to 2.0 seconds of the committed rate, plus the committed
burst
For example, if the committed rate is 1,000,000 bps, the recommended burst sizes
are as follows:
! Committed burst is 1,000,000 x 1.0 x 1/8 = 125,000 bytes
Multiplying the committed rate by 1.0 seconds converts the rate to bits, then
multiplying the number of bits by 1/8 converts the value to bytes.
! Excess burst is 1,000,000 x 1.5 x 1/8 + 125,000 = 312,500 bytes
Multiplying the committed rate by 1.5 converts the rate to bits, then multiplying
the number of bits by 1/8 converts the value to bytes.
TCP-friendly rate limits have only one token bucket, but they also maintain a
cumulative debt counter that represents how much traffic above the committed rate
has recently been seen. This cumulative debt increases until it reaches the extended
burst value; at that point the cumulative debt is reset to 0, but the offending packet
is marked red. The cumulative debt increases faster than just by the packet size, so
if the TCP source does not respond to TCP flow control and more of its packets are
dropped.
Ta b l e 9 presents equations that can also represent the algorithm for the
TCP-friendly one-rate rate limit profile when using hierarchical rate limiting, where:
! B = size of packet in bytes
! CD = cumulative debt
To Next Page
Loading...
Need help?
General
