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).

Table 2-4 Comparison of Shaping and Policing Tools

All functions listed are based on 12.2 mainline IOS code levels.

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 reducing these TCP windows, these particular senders send less traffic into the network, allowing the

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.

Table 2-5 Comparison of Congestion-Avoidance Tools

All functions listed are based on 12.2 mainline IOS code levels.

Chapter 6 covers each of the congestion-avoidance tools in detail.

Link Efficiency

The category of link efficiency encompasses two real topics: compression and fragmentation. Rather than treat these topics in two separate chapters, I have included them in one chapter (Chapter 7, “Link-Efficiency Tools”) to match the organization of the Cisco QoS courses (and the IOS documentation to some degree).

98 Chapter 2: QoS Tools and Architectures

Compression reduces bandwidth utilization by making packets smaller before transmission. Two general types of compression tools exist in IOS—payload compression and header compression. Payload compression compresses the “packet”—the portion of the data link frame between the frame header and trailer. Header compression compresses just particular headers. Figure 2-6 shows the typical scope of the compressed portions of a frame over a PPP link.

Figure 2-6 Scope of Compression for Payload and Header Compression Types

Payload Compression

Payload Compression

Compression tools differ in how much CPU load they create and which parts of the frame they compress. Based on the CPU load and what is compressed, you can make good decisions about when to use each tool.

Payload compression can be applied to all packets, with some good results. Suppose that the compression algorithm manages to compress x bytes of payload into (1/2x)—a reasonable 2:1 compression ratio. The router saves a lot of bandwidth with the compression a 1500-byte packet into a 750-byte packet. Given the variation and unpredictable nature of the contents of the packets, compression ratios between 2:1 and 4:1 are reasonable with payload compression.

Header compression takes advantage of the fact that the headers being compressed are predictable. Much larger compression ratios can be achieved, many times with less CPU load than payload compression. However, header compression only operates on headers. For instance, compressed RTP compresses packets with IP/UDP/RTP headers, as shown in Figure 2-6. The 40 bytes of the IP/UDP/RTP headers compress to between 2 and 4 bytes. For a minimum packet size of 60 bytes, typical of G.729 VoIP calls, cRTP reduces the packet from 60 bytes to between 22 to 24 bytes, a significant improvement.

The other major category of link-efficiency tools is link fragmentation and interleaving (LFI), also just called fragmentation. The concept is simple: When a router starts sending a packet, it never just stops sending that packet in order to send a higher-priority packet—it finishes sending the first packet, and then sends the higher-priority packet. On slow links, the time it takes

Introduction to IOS QoS Tools 99

for one large packet to be serialized may cause too much delay, particularly for VoIP and video traffic. LFI tools fragment large packets into smaller packets, and then interleave the highpriority packet between the fragments. For instance, it takes 214 ms to serialize one 1500-byte packet over a 56-kbps link—which blows the VoIP one-way delay budget. (As described in Chapter 7, Cisco recommends that you considered LFI when the link speed is 768 kbps or less.) Figure 2-7 shows the process of fragmentation.

Figure 2-7 Link Fragmentation and Interleaving

R1

2

Without LFI, packet 2 has to wait 214 ms on the 1500-byte packet. With LFI fragmenting packet 1 into 3 parts, the serialization delay is reduced to about 72 ms.

Link-Efficiency Tools: Summary

Most link-efficiency tools have a very specific application that becomes obvious when you discover what each tool can and cannot do. Not all compression and LFI tools support every type of data link. Both compression and LFI tools may operate on a subset of the packets that exit an interface. For instance, TCP header compression just compresses IP packets that also have TCP headers. Frame Relay fragmentation only operates on a subset of the packets, based on which of two styles of fragmentation is configured. So depending on what you want to accomplish with link efficiency, you can typically use a single tool. Table 2-6 lists the linkefficiency tools and some of the pertinent comparison points.

Chapter 7 covers each of the link-efficiency tools in detail.