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 than 100 to 200 ms. Protocol headers interact with this threshold three ways:
From the above, it's clear that one design goal of the compression should be to limit the bandwidth demand of typing and ack traffic to at most 300 bps. A typical maximum typing speed is around five characters 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 local and adheres to Dave Clark's principle of fate sharing[4]: The two ends can only disagree on the state if the link connecting them is inoperable, in which case the disagreement doesn't matter.