their use of router resources. Compression eliminates redundancy. The protocol header is an item of repeated data. The protocol header information in each packet in the same flow does not change much over the lifetime of that flow. Using header-compression mechanisms, most header information can be sent only at the beginning of the session, stored in a dictionary, and then referenced in later packets by a short dictionary index. The header-compression methods include:
Content 4.8 Understanding WAN Link Efficiency Mechanisms 4.8.3 Layer 2 Payload Compression Figure illustrates the concept of Layer 2 payload compression. When a router forwards a packet, the packet is subjected to the Layer 2 compression method after it has been encapsulated at the output. The compression method squeezes the payload of the Layer 2 frame (the entire Layer 3 packet), and transmits the packet on the interface. Layer 2 payload compression is a CPU-intensive task and can add per-packet compression delay because of the application of the compression method to each frame. The serialization delay, however, is reduced, because the resulting frame is smaller. Serialization delay is the fixed delay that is required to clock the frame onto the network interface. Depending on the complexity of the Layer 2 payload compression algorithm, overall latency might be reduced, especially on low-speed links. Cisco routers support hardware-assisted compression to reduce the CPU load and the Layer 2 payload compression delay. Layer 2 payload compression involves the compression of the payload of a Layer 2 WAN protocol, such as PPP, Frame Relay, High-Level Data Link Control (HDLC), X.25, and Link Access Procedure, Balanced (LAPB). The Layer 2 header is untouched by the act of compression. However, the entire contents of the payload (which include higher-layer protocol headers) are compressed. They are compressed using either a form of the Stacker algorithm (based on the industry standard LZ algorithm) or the Predictor algorithm, which is an older algorithm that is mostly used in legacy configurations. Layer 2 Payload Compression Results
Figure compares three throughput and latency scenarios on a WAN link. If no compression is used, throughput is limited by the link bandwidth, and the average delay is influenced by forwarding or buffering delay, serialization, and propagation delay. If compression is enabled—even if the serialization delay is now shorter because the frame is smaller—the compression or decompression delay may increase the overall latency between the two hops. The perceived throughput is generally increased because the size of the Layer 2 payload is reduced, allowing more Layer 2 frames to be sent through a transmission resource in a given time period. Throughput is limited by the effectiveness of the Layer 2 payload-compression algorithm and may be significantly higher than the link bandwidth limit. If hardware-assisted Layer 2 payload compression is used, compression or decompression delays may become insignificant compared to forwarding and serialization delays, and overall latency may decrease.
Content 4.8 Understanding WAN Link Efficiency Mechanisms 4.8.4 Header Compression Figure illustrates the concept of header compression. Header compression increases throughput and reduces delay by compressing the protocol headers. Header compression is most useful for applications that generate small payloads because the protocol headers of such applications use a significant percentage of bandwidth on a link relative to their payload. Header compression based on session dictionary techniques works by replacing phrases in the input string with indexes from a dictionary table.When header compression is applied on a TCP/IP header, some of the redundant fields in the header of a TCP/IP connection are removed. Header compression keeps a copy of the original header on either side of the link, removes the entirely redundant fields, and differentially codes the remaining fields in order to allow the compression of 40 bytes of header to an average of 5 bytes. This process uses a very specific algorithm designed around the constant structure of the TCP/IP header. It does not touch the payload of the TCP packet in any way. TCP and RTP header compression applies to all TCP and RTP flows. For example, if TCP compression is enabled on a link, there is no mechanism to restrict its function to specific application types. TCP header compression for bulk data transfer yields little bandwidth savings. Class-based TCP header compression can be performed on specific traffic classes, such as the Telnet traffic class. Class-based TCP header compression allows configuring RTP or TCP IP header compression on a per-class basis, when a class is configured within a policy map. Policy maps are created using the Cisco Modular QoS CLI (MQC). The header-compression algorithm tracks active transport layer connections over an interface. After the packet has been forwarded, the header-compression algorithm compresses the Layer 3 and Layer 4 headers within the frame and replaces the headers with a session index from the session dictionary. Only the nonconstant parameters in the headers are sent along with the session index. The packet is then sent to the output queue and transmitted to the remote peer. When the remote peer receives the packet, the header is decompressed using the local session table and passed to the forwarding process. For example, without RTP header compression, the IP, User Datagram Protocol (UDP), and RTP header overhead of the voice packet shown in Figure is about 67 percent (40 / 60 * 100 percent). With RTP header compression, the IP, UDP, and RTP header can be reduced to 2 or 4 bytes (without and with checksum, respectively) for most packets. Thus the IP, UDP, and RTP header overhead can be reduced to about 9 percent (2 / 22 * 100 percent) or 17 percent (4 / 24 * 100 percent). Header Compression Results
Figure compares two throughput and latency scenarios on a WAN link. If header compression is not used, throughput is limited by the link bandwidth, and the average delay is influenced only by forwarding or buffering delay, serialization, and propagation delay. If header compression is enabled, compressing the protocol headers causes the packet to become smaller, allowing more packets to be sent through a transmission resource in a given time period to increase throughput. Because the packet size is smaller, the serialization delay also becomes smaller, reducing the overall delay. Header compression has a low compression delay and a relatively low CPU overhead and is recommended on links slower than 2 Mbps.
Content 4.8 Understanding WAN Link Efficiency Mechanisms 4.8.5 Large Packets “Freeze Out” Voice on Slow WAN Links In considering delay between two hops in a network, queuing delay in a router must be taken into account because it may be comparable to, or even exceed, serialization and propagation delay on a link. In an empty network, an interactive or voice session experiences low or no queuing delay, because the session does not compete with other applications on an interface output queue. Also, the small delay does not vary enough to produce significant jitter on the receiving side. In a congested network, interactive data and voice applications compete in the router queue with other applications. Queuing mechanisms may prioritize voice traffic in the software queue, but the hardware queue (TxQ) always uses a FIFO scheduling mechanism. After packets of different applications leave the software queue, the packets will mix with other packets in the hardware queue, even if their software queue processing was expedited. Thus, a voice packet may be immediately sent to the hardware queue where two large FTP packets are waiting for transmission. The voice packet must wait until the FTP packets are transmitted, thus producing an