rfc1144.txt

RFC 的详细文档！

   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                                                        [Page 1]

   RFC 1144               Compressing TCP/IP Headers          February 1990


   than 100 to 200 ms.  Protocol headers interact with this threshold three
   ways:

   (1) If the line is too slow, it may be impossible to fit both the
       headers and data into a 200 ms window:  One typed character results
       in a 41 byte TCP/IP packet being sent and a 41 byte echo being
       received.  The line speed must be at least 4000 bps to handle these
       82 bytes in 200 ms.

   (2) Even with a line fast enough to handle packetized typing echo (4800
       bps or above), there may be an undesirable interaction between bulk
       data and interactive traffic:  For reasonable line efficiency the
       bulk data packet size needs to be 10 to 20 times the header size.
       I.e., the line maximum transmission unit or MTU should be 500 to
       1000 bytes for 40 byte TCP/IP headers.  Even with type-of-service
       queuing to give priority to interactive traffic, a telnet packet has
       to wait for any in-progress bulk data packet to finish.  Assuming
       data transfer in only one direction, that wait averages half the MTU
       or 500 ms for a 1024 byte MTU at 9600 bps.

   (3) Any communication medium has a maximum signalling rate, the Shannon
       limit.  Based on an AT&T study[2], the Shannon limit for a typical
       dialup phone line is around 22,000 bps.  Since a full duplex, 9600
       bps modem already runs at 80% of the limit, modem manufacturers are
       starting to offer asymmetric allocation schemes to increase
       effective bandwidth:  Since a line rarely has equivalent amounts of
       data flowing both directions simultaneously, it is possible to give
       one end of the line more than 11,000 bps by either time-division
       multiplexing a half-duplex line (e.g., the Telebit Trailblazer) or
       offering a low-speed `reverse channel' (e.g., the USR Courier
       HST)./3/ In either case, the modem dynamically tries to guess which
       end of the conversation needs high bandwidth by assuming one end of
       the conversation is a human (i.e., demand is limited to <300 bps by
       typing speed).  The factor-of-forty bandwidth multiplication due to
       protocol headers will fool this allocation heuristic and cause these
       modems to `thrash'.