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: - TCP
- Real-Time Transport Protocol
(RTP)
- Class-based TCP
- Class-based RTP
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