Link Compression vs. TCP/IP Header Compression:

A Cisco Router Tutorial

By Chris Bryant, CCIE #12933

There are two basic compression types we're going to look at in this section. First, there's link compression, which compresses the header and payload of a data stream, and is protocol-independent. The second is TCP/IP header compression, and the name is definitely the recipe.

When it comes to link compression, we can choose from Predictor or Stacker (STAC). The actual operation of these compression algorithms is out of the scope of this exam, but in short, the Predictor algorithm uses a compression dictionary to predict the next set of characters in a given data stream. Predictor is easier on a router's CPU than other compression techniques, but uses more memory. In contrast, Stacker is much harder on the CPU than Predictor, but uses less memory.

There's a third compression algorithm worth mentioning. Defined in RFC 2118, the Microsoft Point-To-Point Compression makes it possible for a Cisco router to send and receive compressed data to and from a MS client.

To use any of these compression techniques, use the compress interface-level command followed by the compression you want to use. Your options depend on the interface's encapsulation type. On a Serial interface using HDLC encapsulation, stacker is the only option.

R1(config)#int s0
R1(config-if)#encapsulation hdlc
R1(config-if)#compress ?
stac stac compression algorithm

Using PPP encapsulation on the same interface triples our options.

R1(config)#int s0
R1(config-if)#encap ppp
R1(config-if)#compress ?
mppc MPPC compression type
predictor predictor compression type
stac stac compression algorithm
<cr>

Keep in mind that the endpoints of a connection using link compression must agree on the method being used. 

Defined in RFC 1144, TCP/IP Header Compression does just what it says - it compresses the TCP/IP header. Just as obviously, it's protocol-dependent. This particular RFC is very detailed, but it's worth reading, particularly the first few paragraphs where it's noted that TCP/IP HC is truly designed for low-speed serial links.

TCP/IP HC is supported on serial interfaces running HDLC, PPP, or Frame Relay.

Configuring TCP/IP HC is simple, but it's got one interesting option, shown below with IOS Help.

R1(config-if)#ip tcp header-compression ?
passive Compress only for destinations which send compressed headers
<cr>

If the passive option is configured, the only way the local interface will compress TCP/IP headers before transmission is if compressed headers are already being received from the destination.

Finally, if your network requires the headers to remain intact and not compressed, the payload itself can be compressed while leaving the header alone. Frame Relay allows this through the use of the Frame Relay Forum.9, referred to on the router as FRF.9. This can be enabled on a per-VC basis at the very end of the frame map command. The following configuration would compress the payload of frames sent to 172.12.1.1, but the header would remain intact.

R1(config-if)#frame map ip 172.12.1.1 110 broad payload-compression ?
FRF9 FRF9 encapsulation
data-stream cisco proprietary encapsulation
packet-by-packet cisco proprietary encapsulation

R1(config-if)#frame map ip 172.12.1.1 110 broad payload-compression frf9 ?
stac Stac compression algorithm

R1(config-if)#frame map ip 172.12.1.1 110 broad payload-compression frf9 stac

Choosing Between TCP/IP HC And Payload Compression

The main deciding factor here is the speed of the link. If the serial link is slow - and I mean running at 32 kbps or less - TCP/IP HC is the best solution of the two. TCP/IP HC was designed especially for such slow links. By contrast, if the link is running above 32 kbps and less than T1 speed, Layer 2 payload compression is the most effective choice.

What you don't want to do is run them both. The phrase "unpredictable results" best describes what happens if you do. Troubleshooting that is a lot more trouble than it's ever going to be worth. Choose L2 compression or TCP/IP HC in accordance with the link speed, and leave it at that.

To your success,

Chris Bryant

CCIE #12933

chris@thebryantadvantage.com