482 Chapter 7: Link-Efficiency Tools

Foundation Topics

Payload and Header Compression

Compression involves mathematical algorithms that encode the original packet into a smaller string of bytes. After sending the smaller encoded string to the other end of a link, the compression algorithm on the other end of the link reverses the process, reverting the packet back to its original state.

Over the years, many mathematicians and computer scientists have developed new compression algorithms that behave better or worse under particular conditions. For instance, each algorithm takes some amount of computation, some memory, and they result in saving some number

of bytes of data. In fact, you can compare compression algorithms by calculating the ratio of original number of bytes, divided by the compressed number of bytes—a value called the compression ratio. Depending on what is being compressed, the different compression algorithms have varying success with their compression ratios, and each uses different amounts of CPU and memory.

In Cisco routers, compression tools can be divided into two main categories: payload compression and header compression. Payload compression compresses headers and the user data, whereas header compression only compresses headers. As you might guess, payload compression can provide a larger compression ratio for larger packets with lots of user data in them, as compared to header compression tools. Conversely, header compression tools work well when the packets tend to be small, because headers comprise a large percentage of the packet. Figure 7-1 shows the fields compressed by payload compression, and by both types of header compression. (Note that the abbreviation DL stands for data link, representing the data-link header and trailer.)

Figure 7-1 Payload and Header Compression

Payload Compression

TCP Header Compression

RTP Header Compression

DL IP UDP RTP Data DL

Payload and Header Compression 483

Both types of compression tools require CPU cycles and memory. Payload compression algorithms tend to take a little more computation and memory, just based on the fact that they have more bytes to process, as seen in Figure 7-1. With any of the compression tools, however, the computation time required to perform the compression algorithm certainly adds delay to the packet. The bandwidth gained by compression must be more important to you than the delay added by compression processing, otherwise you should choose not to use compression at all!

Figure 7-2 outlines an example showing the delays affected by compression. The compression and decompression algorithms take time, of course. However, serialization delay decreases, because the packets are now smaller. Queuing delay also decreases. In addition, on Frame Relay and ATM networks, the network delay decreases, because the network delay is affected by the amount of bits sent into the network.

Figure 7-2 Delay Versus Bandwidth with Compression

192.168.1.100

Serialization Delay: 15 ms

192.168.1.100

Serialization Delay: 7 ms

This example uses contrived numbers to make the relevant points. The example assumes a 2:1 compression ratio, with a 1500-byte packet, and 768-kbps access links on both ends. The various delay components in the top half of the figure, without compression, add up to 57 ms. In the lower figure, with compression, the delay is still 57 ms. Because a 2:1 compression ratio was achieved, twice as much traffic can be sent without adding delay—it seems like an obvious choice to use compression! However, compression uses CPU and memory, and it is difficult to predict how compression will work on a particular router in a particular network. Compression requires that you try it, monitor CPU utilization, look at the compression ratios, and experiment before just deciding to add it to all routers over an entire network. In addition, although this

484 Chapter 7: Link-Efficiency Tools

example shows no increase in delay, in most cases, just turning on software compression will probably increase delay slightly, but still with the benefit of increasing the amount of traffic you can send over the link.

Compression hardware minimizes the delay added by compression algorithms. Cisco offers several types of hardware compression cards that reduce the delay taken to compress the packets. Cisco offers compression service adapters on 7200, 7300, 7400, 7500 routers, compression advanced integration modules (AIMs) on 3660 and 2600 routers, and compression network modules for 3620s and 3640s. On 7500s with Versatile Interface Processors (VIPs), the compression work can be distributed to the VIP cards, even if no compression adapters are installed. Thankfully, when the compression cards are installed, IOS assumes that you want the compression to occur on the card by default, requiring you to specifically configure software compression if you do not want to use the compression hardware for some reason.

Payload Compression

Cisco IOS Software supplies three different options for point-to-point payload compression tools on serial links, namely Stacker, Microsoft Point-to-Point Compression (MPPC), and Predictor. Consider the following criteria when choosing between the payload compression options:

Of course, when two Cisco routers are used on each end, compatibility is not an issue, although Cisco does recommend that you use the same IOS revision on each end of the link when using compression.

Stacker and MPPC both use the same Lempel-Ziv compression algorithm. Predictor compression is named after the compression algorithm it uses. Predictor tends to take slightly less CPU and memory than does Lempel-Ziv, but Lempel-Ziv typically produces a better compression ratio.

The final factor on which tools to use is whether the tool supports the data-link protocol you are using. Of the three options, Stacker supports more data-link protocols than the other two tools. Table 7-2 outlines the main points of comparison for the three payload compression tools.

Payload and Header Compression 489

The configuration requires only one interface subcommand, compress stacker. You must enter this command on both ends of the serial link before compression will work. The show compress command lists statistics about how well compression is working. For instance, the 1-, 5-, and 10-minute compression ratios for both transmitted and received traffic are listed, which gives you a good idea of how much less bandwidth is being used because of compression.

You can easily configure the other two payload compression tools. Instead of the compress stacker command as in Example 7-1, just use the compress mppc or compress predictor command.

Example 7-2 shows FRF.9 payload compression. The configuration uses a point-to-point subinterface and the familiar network used on most of the other configuration examples in the book, as shown in Figure 7-4.

Figure 7-4 The Network Used in FRF.9 Payload Compression Example

Note: All IP Addresses Begin 192.168.

R4

1001 1002

3001 3002

Example 7-2 FRF.9 Payload Compression Between R1 and R3 (Output from R3)

R3#show running-config

Building configuration...

!

! Lines omitted for brevity

!

interface Serial0/0 description Single PVC to R1. no ip address

encapsulation frame-relay IETF no ip mroute-cache load-interval 30

clockrate 128000

continues

Payload and Header Compression 491

subinterfaces, or use the physical interface, you must configure the same parameters on framerelay map commands.

Regardless of the type of data-link protocol in use, TCP and RTP compression commands allow the use of the passive keyword. The passive keyword means that the router attempts to perform compression only if the router on the other side of the link or VC compresses the traffic. The passive keyword enables you to deploy configurations on remote routers with the passive keyword, and then later add the compression configuration on the local router, at which time compression begins.

The TCP and RTP header compression configuration process, as mentioned, is very simple. Table 7-6 and Table 7-7 list the configuration and show commands, which are followed by a few example configurations.

continues

492 Chapter 7: Link-Efficiency Tools

Table 7-7 Exec Command Reference for TCP and RTP Header Compression (Continued)

The first example uses the same point-to-point link used in the payload compression section, as shown earlier in Figure 7-3. In each example, the same familiar web browsing sessions are used, each downloading two JPGs. An FTP get transfers a file from the server to the client, and two voice calls between R1 and R4 are used.

Example 7-3 example shows TCP header compression on R3.

Example 7-3 TCP Header Compression on R3

R3#show running-config

Building configuration...

!

!Lines omitted for brevity

interface Serial0/1 bandwidth 128

ip address 192.168.12.253 255.255.255.0 encapsulation ppp

ip tcp header-compression clockrate 128000

!Portions omitted for brevity

!

R3#show ip tcp header-compression

TCP/IP header compression statistics:

To enable TCP header compression, the ip tcp header-compression command was added to both serial interfaces on R1 and R3. The show ip tcp header-compression command lists statistics about how well TCP compression is working. For instance, 365 out of 371 packets sent