RFC 1144 (rfc1144) – Page 1 of 46
Compressing TCP/IP headers for low-speed serial links
Alternative Format: Original Text Document
Network Working Group V. Jacobson/1/
Request for Comments: 1144 LBL
February 1990
Compressing TCP/IP Headers
for Low-Speed Serial Links
Status of this Memo
This RFC is a proposed elective protocol for the Internet community and
requests discussion and suggestions for improvement. It describes a
method for compressing the headers of TCP/IP datagrams to improve
performance over low speed serial links. The motivation, implementation
and performance of the method are described. C code for a sample
implementation is given for reference. Distribution of this memo is
unlimited.
NOTE: Both ASCII and Postscript versions of this document are available.
The ASCII version, obviously, lacks all the figures and all the
information encoded in typographic variation (italics, boldface,
etc.). Since this information was, in the author's opinion, an
essential part of the document, the ASCII version is at best
incomplete and at worst misleading. Anyone who plans to work
with this protocol is strongly encouraged obtain the Postscript
version of this RFC.
----------------------------
1. This work was supported in part by the U.S. Department of Energy
under Contract Number DE-AC03-76SF00098.
Contents
1 Introduction 1
2 The problem 1
3 The compression algorithm 4
3.1 The basic idea . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 The ugly details . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.2 Compressed packet format. . . . . . . . . . . . . . . . . 7
3.2.3 Compressor processing . . . . . . . . . . . . . . . . . . 8
3.2.4 Decompressor processing . . . . . . . . . . . . . . . . . 12
4 Error handling 14
4.1 Error detection . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Error recovery . . . . . . . . . . . . . . . . . . . . . . . . 17
5 Configurable parameters and tuning 18
5.1 Compression configuration . . . . . . . . . . . . . . . . . . 18
5.2 Choosing a maximum transmission unit . . . . . . . . . . . . . 20
5.3 Interaction with data compression . . . . . . . . . . . . . . 21
6 Performance measurements 23
7 Acknowlegements 25
A Sample Implementation 27
A.1 Definitions and State Data . . . . . . . . . . . . . . . . . . 28
A.2 Compression . . . . . . . . . . . . . . . . . . . . . . . . . 31
i
A.3 Decompression . . . . . . . . . . . . . . . . . . . . . . . . 37
A.4 Initialization . . . . . . . . . . . . . . . . . . . . . . . . 41
A.5 Berkeley Unix dependencies . . . . . . . . . . . . . . . . . . 41
B Compatibility with past mistakes 43
B.1 Living without a framing `type' byte . . . . . . . . . . . . . 43
B.2 Backwards compatible SLIP servers . . . . . . . . . . . . . . 43
C More aggressive compression 45
D Security Considerations 46
E Author's address 46
ii
RFC 1144 Compressing TCP/IP Headers February 1990
1 Introduction
As increasingly powerful computers find their way into people's homes,
there is growing interest in extending Internet connectivity to those
computers. Unfortunately, this extension exposes some complex problems
in link-level framing, address assignment, routing, authentication and
performance. As of this writing there is active work in all these
areas. This memo describes a method that has been used to improve
TCP/IP performance over low speed (300 to 19,200 bps) serial links.
The compression proposed here is similar in spirit to the Thinwire-II
protocol described in [5]. However, this protocol compresses more
effectively (the average compressed header is 3 bytes compared to 13 in
Thinwire-II) and is both efficient and simple to implement (the Unix
implementation is 250 lines of C and requires, on the average, 90us (170
instructions) for a 20MHz MC68020 to compress or decompress a packet).
This compression is specific to TCP/IP datagrams./2/ The author
investigated compressing UDP/IP datagrams but found that they were too
infrequent to be worth the bother and either there was insufficient
datagram-to-datagram coherence for good compression (e.g., name server
queries) or the higher level protocol headers overwhelmed the cost of
the UDP/IP header (e.g., Sun's RPC/NFS). Separately compressing the IP
and the TCP portions of the datagram was also investigated but rejected
since it increased the average compressed header size by 50% and doubled
the compression and decompression code size.
2 The problem
Internet services one might wish to access over a serial IP link from
home range from interactive `terminal' type connections (e.g., telnet,
rlogin, xterm) to bulk data transfer (e.g., ftp, smtp, nntp). Header
compression is motivated by the need for good interactive response.
I.e., the line efficiency of a protocol is the ratio of the data to
header+data in a datagram. If efficient bulk data transfer is the only
objective, it is always possible to make the datagram large enough to
approach an efficiency of 100%.
Human-factors studies[15] have found that interactive response is
perceived as `bad' when low-level feedback (character echo) takes longer
----------------------------
2. The tie to TCP is deeper than might be obvious. In addition to the
compression `knowing' the format of TCP and IP headers, certain features
of TCP have been used to simplify the compression protocol. In
particular, TCP's reliable delivery and the byte-stream conversation
model have been used to eliminate the need for any kind of error
correction dialog in the protocol (see sec. 4).
Jacobson
