RFC 1144 (rfc1144) - Page 3 of 46

Compressing TCP/IP headers for low-speed serial links

   RFC 1144               Compressing TCP/IP Headers          February 1990


   per second/4/ which leaves a budget 30 - 5 = 25 characters for headers
   or five bytes of header per character typed./5/  Five byte headers solve
   problems (1) and (3) directly and, indirectly, problem (2):  A packet
   size of 100--200 bytes will easily amortize the cost of a five byte
   header and offer a user 95--98% of the line bandwidth for data.  These
   short packets mean little interference between interactive and bulk data
   traffic (see sec. 5.2).

   Another design goal is that the compression protocol be based solely on
   information guaranteed to be known to both ends of a single serial link.
   Consider the topology shown in fig. 1 where communicating hosts A and B
   are on separate local area nets (the heavy black lines) and the nets are
   connected by two serial links (the open lines between gateways C--D and
   E--F)./6/ One compression possibility would be to convert each TCP/IP
   conversation into a semantically equivalent conversation in a protocol
   with smaller headers, e.g., to an X.25 call.  But, because of routing
   transients or multipathing, it's entirely possible that some of the A--B
   traffic will follow the A-C-D-B path and some will follow the A-E-F-B
   path.  Similarly, it's possible that A->B traffic will flow A-C-D-B and
   B->A traffic will flow B-F-E-A. None of the gateways can count on seeing
   all the packets in a particular TCP conversation and a compression
   algorithm that works for such a topology cannot be tied to the TCP
   connection syntax.

   A physical link treated as two, independent, simplex links (one each
   direction) imposes the minimum requirements on topology, routing and
   pipelining.  The ends of each simplex link only have to agree on the
   most recent packet(s) sent on that link.  Thus, although any compression
   scheme involves shared state, this state is spatially and temporally

   ----------------------------
     4. See [13].  Typing bursts or multiple character keystrokes such as
   cursor keys can exceed this average rate by factors of two to four.
   However the bandwidth demand stays approximately constant since the TCP
   Nagle algorithm[8] aggregates traffic with a <200ms interarrival time
   and the improved header-to-data ratio compensates for the increased
   data.
     5. A similar analysis leads to essentially the same header size limit
   for bulk data transfer ack packets.  Assuming that the MTU has been
   selected for `unobtrusive' background file transfers (i.e., chosen so
   the packet time is 200--400 ms --- see sec. 5), there can be at most 5
   data packets per second in the `high bandwidth' direction.  A reasonable
   TCP implementation will ack at most every other data packet so at 5
   bytes per ack the reverse channel bandwidth is 2.5 * 5 = 12.5 bytes/sec.
     6. Note that although the TCP endpoints are A and B, in this example
   compression/decompression must be done at the gateway serial links,
   i.e., between C and D and between E and F. Since A and B are using IP,
   they cannot know that their communication path includes a low speed
   serial link.  It is clearly a requirement that compression not break the
   IP model, i.e., that compression function between intermediate systems
   and not just between end systems.


   Jacobson