Setting Speed Limits on Traffic

Instead of allocating bandwidth for applications, there are instances when you might wish to restrict the amount of bandwidth available for specific traffic. For example, you might want to set a speed limit for users on your network downloading MP3 music files from the Internet.

QoS mechanisms that limit bandwidth are called traffic conditioners. The two categories of traffic conditioners are policing and shaping. While both these approaches limit bandwidth, the mechanisms' operation varies:

  • Policing Policing typically limits bandwidth by discarding any traffic exceeding a specified rate. However, policing can also remark traffic exceeding the specified rate and attempt to send the traffic anyway. Because policing's drop behavior causes TCP retransmits, policing is recommended for higher-speed interfaces. Also, note that policing can be applied inbound or outbound on an interface.

  • Shaping Shaping limits excess traffic, not by dropping traffic, but by buffering it. This buffering of excess traffic can lead to delay. Due to this delay, shaping is recommended for slower-speed interfaces. Unlike policing, shaping lacks the ability to remark traffic. As a final contrast, shaping can only be applied in the outbound direction on an interface.

The question becomes, how do you send traffic out of an interface at a rate less than the physical clock rate of the interface? Many people have the misconception that if they had some sort of police radar gun that could measure the speed of packets exiting an interface, they could point the radar gun at the packets leaving the interface; and the packets would be leaving at a rate slower than the line rate after configuring policing or shaping. That's not possible! Entering a few commands in a router's configuration does not alter the speed configured on an external channel service unit (CSU)/data service unit (DSU).

Here's the secret. For this to be possible, policing and shaping tools don't transmit all of the time. Specifically, these traffic conditioning mechanisms send a certain number of bits or bytes at line rate, and then they stop sending until a specific timing interval (for example, 1/8 of a second) elapses. Once the timing interval is reached, the interface again sends a specific amount of traffic at line rate, and then it stops and waits for the next timing interval. This process continually repeats, allowing an interface to send an average bandwidth that might be below the physical speed of the interface. This average bandwidth is called the Committed Information Rate (CIR). The number of bits (the unit of measure used with shaping tools) or bytes (the unit of measure used with policing tools) that is sent during a timing interval is called the committed burst (Bc). The timing interval is written as Tc. Note, however, that because the router does not send partial frames, if the transmission of a frame begins during a timing interval, the entire frame will be transmitted even if the size of the frame causes more than Bc bits or bytes to be sent during that timing interval.

For example, imagine you have a physical line rate of 128 kbps, but a CIR of only 64 kbps. Also assume there are eight timing intervals in a second (that is, Tc = 1/8 of a second = 125 ms), and during each of those timing intervals, 8000 bits (that is, the Bc value) are sent at line rate. Therefore, over the period of a second, 8000 bits are sent (at line rate) eight times, for a grand total of 64,000 bits per second, which is the CIR, as shown in Figure 6-18.

Figure 6-18. Shaping Example

What if you don't need to send Bc bits (or bytes) during a timing interval? Perhaps you simply don't have enough traffic to need the bandwidth at the moment. There is an option to bank those bits, and use them during a future timing interval. The parameter that allows this storing of unused potential bandwidth is called the Excess Burst (Be) parameter. The Be parameter in a shaping configuration specifies the maximum number of bits that can be sent in excess of the Bc during a timing interval, if those bits are indeed available. For those bits to be available, they must have gone unused during previous timing intervals. Policing tools, however, use the Be parameter to specify the maximum number of bytes that can be sent during a timing interval. Therefore, in a policing configuration, if the Bc equals the Be, then no excess bursting occurs. If excess bursting does occur, then policing tools consider this excess traffic as exceeding traffic (that is, breaking the speed limit). Policing tools consider traffic not exceeding the specified CIR as conforming traffic. As part of your policing configuration, you can specify what action to take when traffic conforms to the CIR and what other action to take when the traffic exceeds the CIR.

To get a bit mathematical for a moment, the relationship between the Tc, Bc, and CIR is given by the formula:

CIR = Bc / Tc

Alternately, the formula can be written as

Tc = Bc / CIR

Therefore, if you want a smaller timing interval, which can reduce delay for voice packets, you could configure a smaller Bc.

To illustrate the operation of traffic conditioners, consider the metaphor of a token bucket, where a router places Bc tokens in the bucket during each timing interval. Also, the bucket's capacity equals Be tokens. In a policing configuration, traffic requiring no more than the Bc number of bits or bytes to be transmitted is called conforming traffic. Traffic requiring more than the Bc number of bytes is said to be exceeding traffic, as shown in Figure 6-19.

Figure 6-19. Token Bucket

Consider a policing example, where there are currently 500 bytes in the token bucket. A packet comes through requiring 300 bytes. The bytes are removed from the bucket, and the packet is sent. Then, before the bucket replenishes with more tokens, another 300-byte packet comes along. Because there are only 200 bytes remaining in the bucket, the packet cannot be sent and is discarded. This illustration describes how policing functions with a single token bucket. However, Cisco also supports a dual token bucket, as shown in Figure 6-20.

Figure 6-20. Dual Token Bucket

Using a dual bucket metaphor, the first bucket has a depth of Bc, and the second bucket has a depth of Be. If a packet can be forwarded using bytes in the Bc bucket, the packet is said to be conforming. If the packet cannot be forwarded using the bytes in the Bc bucket, but it can be forwarded using the bytes in the Be bucket, the traffic is said to be exceeding. If the packet cannot be forwarded using either of the buckets individually, the traffic is said to be violating. Realize, however, a violating packet might still be transmitted if it can be forwarded using the combined tokens (that is, bytes) in both the Bc and Be buckets.

Instead of policing traffic to a single rate, Cisco also supports dual-rate policing, as shown in Figure 6-21. With dual rate policing, the router still uses two token buckets. The first bucket is the Committed Information Rate (CIR) bucket, and the second bucket is the Peak Information Rate (PIR) bucket. These buckets are replenished with tokens at different rates, with the PIR bucket being filled at a faster rate.

Figure 6-21. Dual Rate Token Bucket

When a packet arrives, a dual-rate policer checks to see whether the PIR bucket has enough tokens (that is, bytes) to send the packet. If the PIR bucket lacks sufficient tokens, the packet is said to be violating, and the packet is discarded. Otherwise, the policer checks to see whether the CIR bucket has enough tokens to forward the packet. If the packet can be sent using the CIR bucket's tokens, then the packet is conforming. If the CIR bucket's tokens are not sufficient, but the PIR bucket's tokens are sufficient, the packet is said to be exceeding, and the exceed action (for example, transmit the packet with a DSCP value of AF11) is applied.

With a policing mechanism, you can specify various actions to perform based on whether a packet is conforming, exceeding, or violating. Examples of these actions include

  • Transmit Sends the packet

  • Drop Discards the packet

  • Mark Sets priority bits for the packet

  • Multiaction Performs more than one action, such as marking the packet with a DSCP value of AF12, and setting the CLP bit to a 1

To illustrate how you might use policing in a network, consider the following example. Imagine you wish to restrict HTTP traffic to 100 kbps and Telnet traffic to 50 kbps, as illustrated in Figure 6-22. By limiting the bandwidth of these applications, you make sure these applications don't starve out other, more important traffic, such as voice.

Figure 6-22. Policing

Shaping Frame Relay Networks

On Frame Relay networks, not only might you need to shape your traffic, but you also might need your router to respond to congestion occurring in the service provider's cloud. When a service provider becomes congested and needs to discard frames, the service provider can choose to first discard frames that have their

Discard Eligible (DE) bit set to a 1. The service provider might also request that the sending router slow its transmission rate by marking the Backward Explicit Congestion Notification (BECN) bit to a 1, in a frame going back to the sender, as shown in Figure 6-23. When BECN marking occurs, if the originating router is configured to respond to BECNs, the originating router reduces its CIR by 25 percent. If the router receives another BECN in the next time interval, it decreases its transmission rate by 25 percent of the current rate. This behavior can continue until the rate drops to the router's configured minimum CIR, the rate below which the router refuses to go.

Figure 6-23. Backward Explicit Congestion Notification

You might, however, encounter a situation where the vast majority of the traffic flowing over the Frame Relay network flows in only one direction, from one router to another router (that is, with little, if any, return traffic). In such a situation, the service provider cannot mark a BECN bit in a frame going back to the sender because there are no (or very few) frames going back to the sender. To remedy this situation, the service provider can mark the Forward Explicit Congestion Notification (FECN) bit in a frame destined for the receiver. If the receiving router is configured to respond to FECNs, it generates a meaningless frame, called a Q.922 test frame, and sends the frame back to the sender. This test frame allows the service provider the opportunity to mark that frame's BECN bit, in an attempt to make the sender slow its transmission rate, as shown in Figure 6-24.

Figure 6-24. Forward Explicit Congestion Notification

After a sender slows its transmission rate due to BECNs, 16 timing intervals must elapse before the sender begins to increase its transmission rate. When the sender does increase its transmission rate, it does so at a much more cautious pace than when it reduced its rate. Specifically, the sender only increases its transmission rate by (Be + Bc)/16 bits per timing interval.

Voice over IP First-Step
Voice over IP First-Step
ISBN: 1587201569
EAN: 2147483647
Year: 2005
Pages: 138
Authors: Kevin Wallace

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: