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.