Because shaping and policing provide two different functions, you may wonder why shaping and policing are covered here at the same time. The simple answer is this: Networks that use policing typically need shaping as well. Also both shaping and policing measure the rates at which traffic is sent and received in a network, so some of the underlying features are similar.
Both can be described using similar metaphors of “token buckets.” Finally, from a business perspective, shaping and policing are typically implemented at or near the edge between an enterprise and a service provider. Therefore, when considering whether you need to use one type of tool, you need to be thinking about the other type.
Traffic shaping, or shaping, delays packets by putting packets in a queue, even when real bandwidth is available. It’s like being at the bank. A teller finishes with a customer, and you’re next in line. You have to wait another minute or two, however, while the teller finishes doing some paperwork for the preceding customer. Why would a router ever want to delay packets?
Well, the short answer is “because delaying these packets is better than what happens if you don’t delay them.” Figure 2-4 shows just one example where shaping is useful.
Figure 2-4 Sample Network, Speed Mismatch (T/1 and 128 kbps)
This example results in a large queue forming at Frame Relay Switch 2 (FRS2) due to the speed mismatch between the access links at R2 and R3. In this example, 50 1500-byte packets arrive over R3’s Ethernet during a 500-ms span, needing to be delivered to R2. If all 50 packets were to arrive one after the other, with no gaps, a queue would form on R3’s S0 interface. Because it takes a little less than 10 ms to send a 1500-byte packet over T/1, however, all 50 packets would drain from the queue within that 500 ms.
FIFO Output Queue
R2 1 2 3 4 ...Up to 50
AR:
128 kbps
FRS2 FRS3
CIR: 64 kbps Bc: 12,000 bits
AR: T1
Queue Backs up on FRS2
50 x 1500 Byte Packets from Local LAN Users R3
Figure Shows QoS for Packets Flows Right-to-Left
94 Chapter 2: QoS Tools and Architectures
However, because the access link between FRS2 and R2 clocks at 128 kbps, it takes almost 100 ms to serialize a 1500-byte packet. So, although some queuing happens at R3, FRS2’s egress queue on the link to R2 fills—in this case, it needs to be 45 packets long. (Five packets could be sent over this link during the 500 ms that the rest of the packets are arriving.)
What happens if FRS2’s maximum egress queue size is only 20 frames? In such a scenario, around half of the frames are discarded. What is the impact? The quality of voice and video streams degrades. Most data applications resend their data—which may well cause the same phenomena all over again. Both results, of course, are bad.
Traffic shaping solves this particular problem. If R3 had just waited and sent one 1500-byte packet every 100 ms, because FRS2 can send one 1500-byte packet in a little less than 100 ms, no queue would have formed on FRS2’s egress interface. Even if R3 were to send one 1500-byte packet every 50 ms, FRS2’s egress queue would grow, but only a few packets would be lost.
Whenever a speed mismatch occurs, shaping may be able to reduce the chance that packets get dropped. In the previous example, a speed mismatch occurred on the access rates of two Frame Relay-connected routers. In other cases, it may be that many VCs terminate at one router, and the collective VC committed information rate (CIRs) far exceed the access rate (oversubscrip-tion). In either case, queues may form, and they may form in a place where the engineer cannot control the queue—inside the Frame Relay cloud.
Shaping may help in one other specific case: when the Frame Relay service provider uses polic-ing. The service provider may need to limit a VC to use just the CIR amount of bandwidth. Most providers, as well as their customers, expect the Frame Relay data terminal equipment (DTE) to send more than the CIR across each VC. However, the provider may decide that in this case, they need to prevent R3 and R2 from sending more than CIR. Why? For many reasons, but one common reason may be that a particular part of their network may have enough capacity to sup-port the CIRs of all VCs for all customers, but not much bandwidth beyond that. To protect cus-tomers from each other, the provider may limit each VC to CIR, or some percentage over CIR, and discard the excess traffic.
The QoS tool used to monitor the rate, and discard the excess traffic, is called traffic policing, or just policing. Because the provider is monitoring traffic sent by the customer, traffic policers typically monitor ingress traffic, although they can monitor egress traffic as well. Figure 2-5 shows the same network, but with policing and shaping enabled for traffic entering FRS3 from R3.
Introduction to IOS QoS Tools 95
Figure 2-5 Traffic Policing and Shaping
In the shaping discussion, one solution involved sending only one 1500-byte packet every 100 ms, which prevented an egress queue from forming on FRS2. As seen in this figure, however, the ingress policer on FRS3 monitors incoming traffic on the VC from R3 to R2, allowing only one 1500-byte packet per 200 ms. Policers discard the excess traffic, which in this case, even with shaping enabled on R3, half of the packets will be discarded when the network is busy!
The solution, when the provider enables policing, is to configure shaping such that R3 only sends traffic at a rate that the policer function allows. In summary, some of the reasons behind shaping and policing are as follows:
•
Packets might be lost in a multiaccess WAN due to access rate speed mismatch, oversubscription of CIRs over an access link, or by policing performed by the provider.•
Traffic shaping queues packets when configured traffic rates are exceeded, delaying those packets, to avoid likely packet loss.•
Traffic policing discards packets when configured traffic rates are exceeded, protecting other flows from being overrun by a particular customer.Shaping and Policing Tools
QoS shaping and policing tools provide you with a variety of methods. As usual, you may consider many factors when comparing these tools. (Table 2-4 lists a few of these factors.) First, not all shaping and policing tools support every data-link protocol. Second, some tools can be enabled on a subinterface, but not on a per data-link connection identifier (DLCI); therefore, in cases where a network uses multipoint subinterfaces, one tool may give more granularity for
Step 4:
96 Chapter 2: QoS Tools and Architectures
shaping/policing. With regard to policers, some categorize packets as either conforming to or exceeding a traffic contract (called a two-headed policer), and some categorize packets as either conforming to, exceeding, or violating a traffic contract (a three-headed policer).
Chapter 5, “Traffic Policing and Shaping,” covers each of the policing and shaping tools in detail.
Congestion Avoidance
When networks become congested, output queues begin to fill. When new packets need to be added to a full queue, the packet is dropped—a process called tail drop. Tail drop happens in most networks every day—but to what effect? Packet loss degrades voice and video flows significantly; for data flows, packet loss causes higher-layer retransmissions for TCP-based applications, which probably increases network congestion.
Two solutions to the tail-drop problem exist. One solution is to lengthen queues, and thereby lessen the likelihood of tail drop. With longer queues, fewer packets are tail dropped, but the average queuing delay is increased. The other solution requires the network to ask the devices sending the packets into the network to slow down before the queues fill—which is exactly what the congestion-avoidance QoS tools do.
Congestion-avoidance tools operate under the assumption that a dropped TCP segment causes the sender of the TCP segment to reduce its congestion window to 50 percent of the previous window. If a router experiences congestion, before its queues fill, it can purposefully discard several TCP segments, making a few of the TCP senders reduce their window sizes. By reduc-ing these TCP windows, these particular senders send less traffic into the network, allowreduc-ing the Table 2-4 Comparison of Shaping and Policing Tools
All functions listed are based on 12.2 mainline IOS code levels.
Tool
Policer All that are supported by Cisco Express Forwarding (CEF)
Per subinterface
Committed access rate (CAR)
Policer All that are supported by CEF Per subinterface Class-based shaping Shaper All that are supported by CEF Per subinterface Generic traffic shaping/
distributed traffic shaping (GTS/DTS)
Shaper Frame, ATM, SMDS, Ethernet Per subinterface
Frame Relay traffic shaping (FRTS)
Shaper Frame Per DLCI
Introduction to IOS QoS Tools 97
congested router’s queues time to recover. If the queues continue to grow, more TCP segments are purposefully dropped, to make more TCP senders slow down. If the queues become less congested, the router can stop discarding packets.
Congestion-Avoidance Tools
This book covers three congestion-avoidance tools. One of the tools was never implemented in IOS (Random Early Detection, or RED)—but because the other two features are based on RED concepts, Chapter 6, “Congestion Avoidance Through Drop Policies,” covers the basics of RED as well.
All Congestion-avoidance tools consider the queue depth—the number of packets in a queue—
when deciding whether to drop a packet. Some tools weigh the likelihood of dropping a packet based on the IP precedence or IP DSCP value. Finally, one congestion-avoidance tool considers the actual flow in addition to the queue depth and weight, and treats some flows differently based on their characteristics. Table 2-5 lists the tools and the various points for comparison.
Chapter 6 covers each of the congestion-avoidance tools in detail.