Internet services one might wish to access over a remote serial IP link range from interactive terminal type connections (e.g., telnet, rlogin, xterm) to bulk data transfer (e.g., ftp, smtp). Unfortunately, this extension exposes some complex problems in link-level framing, address assignment, routing, authentication and performance. 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[Sheniderman 87] have found that interactive response is precieved as bad when low-level feedback (character echo) takes longer than 100 to 200 ms. For example 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. From this fact it is clear that one design goal of the compression should be to limit the bandwidth demand of typing and ack traffic to at most 300bps.
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. Note that a physical link treated as two, independent, simplex links (one each direction) imposes the minimum requirements on topology, routing and pipelining.