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