RFC 1144 (rfc1144) - Page 3 of 46
Compressing TCP/IP headers for low-speed serial links
Alternative Format: Original Text Document
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