Compression

HDLC Frame Compression

The PPP frame format is based on the established HDLC format. Synchronous PPP links almost always use the full PPP/HDLC frame because the link hardware supports it. But lower-speed asynchronous links typically handle framing in software and several of the fields carry the same contents in each message. Therefore, it makes sense to amend the full HDLC frame for asynchronous PPP.

Address and Control Field Compression

A full PPP frame contains the HDLC ALLSTATIONS value (0xFF) in the address field, and the HDLC Un-numbered information value (0x03) in the control field. These fields are unnecessary because they always carry the same information and increase the latency of a low-speed link. During the Link Control Protocol (LCP) phase, asynchronous PPP links usually negotiate to drop both fields. When the LCP layer is opened, the fields are not transmitted in PPP frames.

Protocol Field Compression

The two-octet PPP Protocol field in an asynchronous PPP frame tells the receiving PPP whether the incoming frame carries an IP network datagram, a Link Quality Report, a link option (re)negotiation, or any of several other types of data. Though option negotiations and other link-level traffic always require two octets, most of an established link's traffic is network-layer (for example, IP) datagrams. PPP's network-layer protocol field values always place a null octet (0x00) before the octet that distinguishes IP (0x21) from Appletalk (0x29) datagrams. That octet almost always contains the same value (0x00), and asynchronous PPP links usually negotiate it away to reduce latency.

Van Jacobson TCP Header Compression

Each layer a TCP/IP datagram passes through adds a header to the user data. For example, many streams can potentially pass between two hosts. Therefore, in addition to its source and destination addresses, each packet contains a tag to identify which stream it belongs to. These headers are very large, and a comparison between successive packets reveals strong similarities.

RFC 1144 'VJ' TCP header compression reduces the packet header size by transmitting only the header segments that change from one packet to the next. TCP and IP header overhead is reduced from over 40 octets to as few as 4. TCP header compression has a dramatic effect on interactive responsiveness over low-speed links, because it reduces a typical single-character Telnet or rlogin packet from over 40 octets to 5 or 6 octets. It has a much smaller effect on batch data throughput, like X bitmap displays, or FTP or rcp file transfers. That sort of data flows in much larger packets. Reducing frame size from 1500 to 1460 octets produces a much smaller percentage improvement than a reduction from 45 to 5 octets.

The option vjslots followed by a numerical value between 3 and 256 sets the number of compression slots for Van Jacobson compression. The default is 16 slots. See the pppd man pages for other options for VJ compression.

TCP header compression is enabled by default on asynchronous PPP and SLIP links, and disabled by default on synchronous PPP links.

PPP Link Compression

Like in-modem data compression, PPP link compression reduces the amount of data that must flow across a low-bandwidth telephone line, thus increasing its effective bandwidth. Since PPP link compression in pppd is performed on the UNIX system, less data flows across the serial interface. This is advantageous in the following situations:

PPP link compression over modems that support V.42bis compression may provide no performance advantage, except in cases where the link's bandwidth is limited by slow serial interfaces.

Predictor-1

Predictor-1 compresses typical binary data 1.5:1, absorbs relatively little of the host's CPU, and adds very little latency to interactive traffic. It is well suited to achieving even better performance from higher-speed synchronous PPP connections.

Stac Compression

The Stac LZS algorithm for data compression is an Internet Engineering Task Force (IETF) compression standard for PPP. The algorithm can maintain an average 2:1 compression ratio and, depending on the type of data that is being compressed, the ratio may be as high as 3:1 or 5:1 . The Stac LZS algorithm is based on the Lempel-Ziv algorithm and is the same as that used in Stac Electronics retail software.