As per Relevance of the word february, we have this rfc below:
Network Working Group V. Jacobson/1/
Request for Comments: 1144
February 1990
Compressing TCP/IP
for Low-Speed Serial
Status of this
This RFC is a proposed elective protocol for the Internet community
requests discussion and suggestions for improvement. It describes
method for compressing the headers of TCP/IP datagrams to
performance over low speed serial links. The motivation,
and performance of the method are described. C code for a
implementation is given for reference. Distribution of this memo
unlimited
NOTE: Both ASCII and Postscript versions of this document are available
The ASCII version, obviously, lacks all the figures and all
information encoded in typographic variation (italics, boldface
etc.). Since this information was, in the author's opinion,
essential part of the document, the ASCII version is at
incomplete and at worst misleading. Anyone who plans to
with this protocol is strongly encouraged obtain the
version of this RFC
----------------------------
1. This work was supported in part by the U.S. Department of
under Contract Number DE-AC03-76SF00098.
1 Introduction 1
2 The problem 1
3 The compression algorithm 4
3.1 The basic idea . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 The ugly details . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.2 Compressed packet format. . . . . . . . . . . . . . . . . 7
3.2.3 Compressor processing . . . . . . . . . . . . . . . . . . 8
3.2.4 Decompressor processing . . . . . . . . . . . . . . . . . 12
4 Error handling 14
4.1 Error detection . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Error recovery . . . . . . . . . . . . . . . . . . . . . . . . 17
5 Configurable parameters and tuning 18
5.1 Compression configuration . . . . . . . . . . . . . . . . . . 18
5.2 Choosing a maximum transmission unit . . . . . . . . . . . . . 20
5.3 Interaction with data compression . . . . . . . . . . . . . . 21
6 Performance measurements 23
7 Acknowlegements 25
A Sample Implementation 27
A.1 Definitions and State Data . . . . . . . . . . . . . . . . . . 28
A.2 Compression . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.3 Decompression . . . . . . . . . . . . . . . . . . . . . . . . 37
A.4 Initialization . . . . . . . . . . . . . . . . . . . . . . . . 41
A.5 Berkeley Unix dependencies . . . . . . . . . . . . . . . . . . 41
B Compatibility with past mistakes 43
B.1 Living without a framing `type' byte . . . . . . . . . . . . . 43
B.2 Backwards compatible SLIP servers . . . . . . . . . . . . . . 43
C More aggressive compression 45
D Security Considerations 46
E Author's address 46
RFC 1144 Compressing TCP/IP Headers February 1990
1
As increasingly powerful computers find their way into people's homes
there is growing interest in extending Internet connectivity to
computers. Unfortunately, this extension exposes some complex
in link-level framing, address assignment, routing, authentication
performance. As of this writing there is active work in all
areas. This memo describes a method that has been used to
TCP/IP performance over low speed (300 to 19,200 bps) serial links
The compression proposed here is similar in spirit to the Thinwire-
protocol described in [5]. However, this protocol compresses
effectively (the average compressed header is 3 bytes compared to 13
Thinwire-II) and is both efficient and simple to implement (the
implementation is 250 lines of C and requires, on the average, 90us (170
instructions) for a 20MHz MC68020 to compress or decompress a packet).
This compression is specific to TCP/IP datagrams./2/ The
investigated compressing UDP/IP datagrams but found that they were
infrequent to be worth the bother and either there was
datagram-to-datagram coherence for good compression (e.g., name
queries) or the higher level protocol headers overwhelmed the cost
the UDP/IP header (e.g., Sun's RPC/NFS). Separately compressing the
and the TCP portions of the datagram was also investigated but
since it increased the average compressed header size by 50% and
the compression and decompression code size
2 The
Internet services one might wish to access over a serial IP link
home range from interactive `terminal' type connections (e.g., telnet
rlogin, xterm) to bulk data transfer (e.g., ftp, smtp, nntp).
compression is motivated by the need for good interactive response
I.e., the line efficiency of a protocol is the ratio of the data
header+data in a datagram. If efficient bulk data transfer is the
objective, it is always possible to make the datagram large enough
approach an efficiency of 100%.
Human-factors studies[15] have found that interactive response
perceived as `bad' when low-level feedback (character echo) takes
----------------------------
2. The tie to TCP is deeper than might be obvious. In addition to
compression `knowing' the format of TCP and IP headers, certain
of TCP have been used to simplify the compression protocol.
particular, TCP's reliable delivery and the byte-stream
model have been used to eliminate the need for any kind of
correction dialog in the protocol (see sec. 4).
Jacobson [Page 1]
RFC 1144 Compressing TCP/IP Headers February 1990
than 100 to 200 ms. Protocol headers interact with this threshold
ways
(1) If the line is too slow, it may be impossible to fit both
headers and data into a 200 ms window: One typed character
in a 41 byte TCP/IP packet being sent and a 41 byte echo
received. The line speed must be at least 4000 bps to handle
82 bytes in 200 ms
(2) Even with a line fast enough to handle packetized typing echo (4800
bps or above), there may be an undesirable interaction between
data and interactive traffic: For reasonable line efficiency
bulk data packet size needs to be 10 to 20 times the header size
I.e., the line maximum transmission unit or MTU should be 500
1000 bytes for 40 byte TCP/IP headers. Even with type-of-
queuing to give priority to interactive traffic, a telnet packet
to wait for any in-progress bulk data packet to finish.
data transfer in only one direction, that wait averages half the
or 500 ms for a 1024 byte MTU at 9600 bps
(3) Any communication medium has a maximum signalling rate, the
limit. Based on an AT&T study[2], the Shannon limit for a
dialup phone line is around 22,000 bps. Since a full duplex, 9600
bps modem already runs at 80% of the limit, modem manufacturers
starting to offer asymmetric allocation schemes to
effective bandwidth: Since a line rarely has equivalent amounts
data flowing both directions simultaneously, it is possible to
one end of the line more than 11,000 bps by either time-
multiplexing a half-duplex line (e.g., the Telebit Trailblazer)
offering a low-speed `reverse channel' (e.g., the USR
HST)./3/ In either case, the modem dynamically tries to guess
end of the conversation needs high bandwidth by assuming one end
the conversation is a human (i.e., demand is limited to <300 bps
typing speed). The factor-of-forty bandwidth multiplication due
protocol headers will fool this allocation heuristic and cause
modems to `thrash'.
From the above, it's clear that one design goal of the
should be to limit the bandwidth demand of typing and ack traffic to
most 300 bps. A typical maximum typing speed is around five
----------------------------
3. See the excellent discussion of two-wire dialup line capacity
[1], chap. 11. In particular, there is widespread misunderstanding
the capabilities of `echo-cancelling' modems (such as those
to CCITT V.32): Echo-cancellation can offer each side of a two-
line the full line bandwidth but, since the far talker's signal adds
the local `noise', not the full line capacity. The 22Kbps Shannon
is a hard-limit on data rate through a two-wire telephone connection
Jacobson [Page 2]
RFC 1144 Compressing TCP/IP Headers February 1990
per second/4/ which leaves a budget 30 - 5 = 25 characters for
or five bytes of header per character typed./5/ Five byte headers
problems (1) and (3) directly and, indirectly, problem (2): A
size of 100--200 bytes will easily amortize the cost of a five
header and offer a user 95--98% of the line bandwidth for data.
short packets mean little interference between interactive and bulk
traffic (see sec. 5.2).
Another design goal is that the compression protocol be based solely
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
are on separate local area nets (the heavy black lines) and the nets
connected by two serial links (the open lines between gateways C--D
E--F)./6/ One compression possibility would be to convert each TCP/
conversation into a semantically equivalent conversation in a
with smaller headers, e.g., to an X.25 call. But, because of
transients or multipathing, it's entirely possible that some of the A--
traffic will follow the A-C-D-B path and some will follow the A-E-F-
path. Similarly, it's possible that A->B traffic will flow A-C-D-B
B->A traffic will flow B-F-E-A. None of the gateways can count on
all the packets in a particular TCP conversation and a
algorithm that works for such a topology cannot be tied to the
connection syntax
A physical link treated as two, independent, simplex links (one
direction) imposes the minimum requirements on topology, routing
pipelining. The ends of each simplex link only have to agree on
most recent packet(s) sent on that link. Thus, although any
scheme involves shared state, this state is spatially and
----------------------------
4. See [13]. Typing bursts or multiple character keystrokes such
cursor keys can exceed this average rate by factors of two to four
However the bandwidth demand stays approximately constant since the
Nagle algorithm[8] aggregates traffic with a <200ms interarrival
and the improved header-to-data ratio compensates for the
data
5. A similar analysis leads to essentially the same header size
for bulk data transfer ack packets. Assuming that the MTU has
selected for `unobtrusive' background file transfers (i.e., chosen
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
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
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
serial link. It is clearly a requirement that compression not break
IP model, i.e., that compression function between intermediate
and not just between end systems
Jacobson [Page 3]
RFC 1144 Compressing TCP/IP Headers February 1990
local and adheres to Dave Clark's principle of fate sharing[4]: The
ends can only disagree on the state if the link connecting them
inoperable, in which case the disagreement doesn't matter
3 The compression
3.1 The basic
Figure 2 shows a typical (and minimum length) TCP/IP datagram header./7/
The header size is 40 bytes: 20 bytes of IP and 20 of TCP
Unfortunately, since the TCP and IP protocols were not designed by
committee, all these header fields serve some useful purpose and it'
not possible to simply omit some in the name of efficiency
However, TCP establishes connections and, typically, tens or hundreds
packets are exchanged on each connection. How much of the per-
information is likely to stay constant over the life of a connection
Half---the shaded fields in fig. 3. So, if the sender and receiver
track of active connections/8/ and the receiver keeps a copy of
header from the last packet it saw from each connection, the sender
a factor-of-two compression by sending only a small (<= 8 bit
connection identifier together with the 20 bytes that change and
the receiver fill in the 20 fixed bytes from the saved header
One can scavenge a few more bytes by noting that any
link-level framing protocol will tell the receiver the length of
received message so total length (bytes 2 and 3) is redundant. But
the header checksum (bytes 10 and 11), which protects individual
from processing a corrupted IP header, is essentially the only part
the IP header being sent. It seems rather silly to protect
transmission of information that isn't being transmitted. So,
receiver can check the header checksum when the header is actually
(i.e., in an uncompressed datagram) but, for compressed datagrams
regenerate it locally at the same time the rest of the IP header
being regenerated./9/
----------------------------
7. The TCP and IP protocols and protocol headers are described in [10]
and [11].
8. The 96-bit tuple
uniquely identifies a TCP connection
9. The IP header checksum is not an end-to-end checksum in the
of [14]: The time-to-live update forces the IP checksum to
recomputed at each hop. The author has had unpleasant
experience with the consequences of violating the end-to-end argument
[14] and this protocol is careful to pass the end-to-end TCP
through unmodified. See sec. 4.
Jacobson [Page 4]
RFC 1144 Compressing TCP/IP Headers February 1990
This leaves 16 bytes of header information to send. All of these
are likely to change over the life of the conversation but they do
all change at the same time. For example, during an FTP data
only the packet ID, sequence number and checksum change in
sender->receiver direction and only the packet ID, ack, checksum and
possibly, window, change in the receiver->sender direction. With a
of the last packet sent for each connection, the sender can figure
what fields change in the current packet then send a bitmask
what changed followed by the changing fields./10/
If the sender only sends fields that differ, the above scheme gets
average header size down to around ten bytes. However, it's
looking at how the fields change: The packet ID typically comes from
counter that is incremented by one for each packet sent. I.e.,
difference between the current and previous packet IDs should be
small, positive integer, usually <256 (one byte) and frequently = 1.
For packets from the sender side of a data transfer, the sequence
in the current packet will be the sequence number in the previous
plus the amount of data in the previous packet (assuming the packets
arriving in order). Since IP packets can be at most 64K, the
number change must be < 2^16 (two bytes). So, if the differences in
changing fields are sent rather than the fields themselves,
three or four bytes per packet can be saved
That gets us to the five-byte header target. Recognizing a couple
special cases will get us three byte headers for the two most
cases---interactive typing traffic and bulk data transfer---but
basic compression scheme is the differential coding developed above
Given that this intellectual exercise suggests it is possible to
five byte headers, it seems reasonable to flesh out the missing
and actually implement something
3.2 The ugly
3.2.1
Figure 4 shows a block diagram of the compression software.
networking system calls a SLIP output driver with an IP packet to
----------------------------
10. This is approximately Thinwire-I from [5]. A slight
is to do a `delta encoding' where the sender subtracts the
packet from the current packet (treating each packet as an array of 16
bit integers), then sends a 20-bit mask indicating the non-
differences followed by those differences. If distinct
are separated, this is a fairly effective compression scheme (e.g.,
typically 12-16 byte headers) that doesn't involve the
knowing any details of the packet structure. Variations on this
have been used, successfully, for a number of years (e.g., the
router's serial link protocol[3]).
Jacobson [Page 5]
RFC 1144 Compressing TCP/IP Headers February 1990
sent over the serial line. The packet goes through a compressor
checks if the protocol is TCP. Non-TCP packets and `uncompressible'
packets (described below) are just marked as TYPE_IP and passed to
framer. Compressible TCP packets are looked up in an array of
headers. If a matching connection is found, the incoming packet
compressed, the (uncompressed) packet header is copied into the array
and a packet of type COMPRESSED_TCP is sent to the framer. If no
is found, the oldest entry in the array is discarded, the packet
is copied into that slot, and a packet of type UNCOMPRESSED_TCP is
to the framer. (An UNCOMPRESSED_TCP packet is identical to the
IP packet except the IP protocol field is replaced with a
number---an index into the array of saved, per-connection
headers. This is how the sender (re-)synchronizes the receiver
`seeds' it with the first, uncompressed packet of a compressed
sequence.)
The framer is responsible for communicating the packet data, type
boundary (so the decompressor can learn how many bytes came out of
compressor). Since the compression is a differential coding, the
must not re-order packets (this is rarely a concern over a single
link). It must also provide good error detection and, if
numbers are compressed, must provide an error indication to
decompressor (see sec. 4)./11/
The decompressor does a `switch' on the type of incoming packets:
TYPE_IP, the packet is simply passed through. For UNCOMPRESSED_TCP,
connection number is extracted from the IP protocol field
IPPROTO_TCP is restored, then the connection number is used as an
into the receiver's array of saved TCP/IP headers and the header of
incoming packet is copied into the indexed slot. For COMPRESSED_TCP
the connection number is used as an array index to get the TCP/IP
of the last packet from that connection, the info in the
packet is used to update that header, then a new packet is
containing the now-current header from the array concatenated with
data from the compressed packet
Note that the communication is simplex---no information flows in
decompressor-to-compressor direction. In particular, this implies
the decompressor is relying on TCP retransmissions to correct the
state in the event of line errors (see sec. 4).
----------------------------
11. Link level framing is outside the scope of this document.
framing that provides the facilities listed in this paragraph should
adequate for the compression protocol. However, the author
potential implementors to see [9] for a proposed, standard,
framing
Jacobson [Page 6]
RFC 1144 Compressing TCP/IP Headers February 1990
3.2.2 Compressed packet
Figure 5 shows the format of a compressed TCP/IP packet. There is
change mask that identifies which of the fields expected to
per-packet actually changed, a connection number so the receiver
locate the saved copy of the last packet for this TCP connection,
unmodified TCP checksum so the end-to-end data integrity check
still be valid, then for each bit set in the change mask, the amount
associated field changed. (Optional fields, controlled by the mask,
enclosed in dashed lines in the figure.) In all cases, the bit is
if the associated field is present and clear if the field is absent./12/
Since the delta's in the sequence number, etc., are usually small
particularly if the tuning guidelines in section 5 are followed, all
numbers are encoded in a variable length scheme that, in practice
handles most traffic with eight bits: A change of one through 255
represented in one byte. Zero is improbable (a change of zero is
sent) so a byte of zero signals an extension: The next two bytes
the MSB and LSB, respectively, of a 16 bit value. Numbers larger
16 bits force an uncompressed packet to be sent. For example,
15 is encoded as hex 0f, 255 as ff, 65534 as 00 ff fe, and zero as 00 00
00. This scheme packs and decodes fairly efficiently: The usual
for both encode and decode executes three instructions on a MC680x0.
The numbers sent for TCP sequence number and ack are the difference/13/
between the current value and the value in the previous packet (
uncompressed packet is sent if the difference is negative or more
64K). The number sent for the window is also the difference between
current and previous values. However, either positive or
changes are allowed since the window is a 16 bit field. The packet'
urgent pointer is sent if URG is set (an uncompressed packet is sent
the urgent pointer changes but URG is not set). For packet ID,
number sent is the difference between the current and previous values
However, unlike the rest of the compressed fields, the assumed
when I is clear is one, not zero
There are two important special cases
(1) The sequence number and ack both change by the amount of data in
last packet; no window change or URG
(2) The sequence number changes by the amount of data in the
packet, no ack or window change or URG
----------------------------
12. The bit `P' in the figure is different from the others: It is
copy of the `PUSH' bit from the TCP header. `PUSH' is a
anachronism considered indispensable by certain members of the
community. Since PUSH can (and does) change in any datagram,
information preserving compression scheme must pass it explicitly
13. All differences are computed using two's complement arithmetic
Jacobson [Page 7]
RFC 1144 Compressing TCP/IP Headers February 1990
(1) is the case for echoed terminal traffic. (2) is the sender side
non-echoed terminal traffic or a unidirectional data transfer.
combinations of the S, A, W and U bits of the change mask are used
signal these special cases. `U' (urgent data) is rare so two
combinations are S W U (used for case 1) and S A W U (used for case 2).
To avoid ambiguity, an uncompressed packet is sent if the actual
in a packet are S * W U
Since the `active' connection changes rarely (e.g., a user will type
several minutes in a telnet window before changing to a
window), the C bit allows the connection number to be elided. If C
clear, the connection is assumed to be the same as for the
compressed or uncompressed packet. If C is set, the connection
is in the byte immediately following the change mask./14/
From the above, it's probably obvious that compressed terminal
usually looks like (in hex): 0B c c d, where the 0B indicates case (1),
c c is the two byte TCP checksum and d is the character typed.
to vi or emacs, or packets in the data transfer direction of an
`put' or `get' look like 0F c c d ... , and acks for that FTP look
04 c c a where a is the amount of data being acked./15/
3.2.3 Compressor
The compressor is called with the IP packet to be processed and
compression state structure for the outgoing serial line. It returns
packet ready for final framing and the link level `type' of that packet
As the last section noted, the compressor converts every input
into either a TYPE_IP, UNCOMPRESSED_TCP or COMPRESSED_TCP packet.
----------------------------
14. The connection number is limited to one byte, i.e., 256
simultaneously active TCP connections. In almost two years
operation, the author has never seen a case where more than
connection states would be useful (even in one case where the SLIP
was used as a gateway behind a very busy, 64-port terminal multiplexor).
Thus this does not seem to be a significant restriction and allows
protocol field in UNCOMPRESSED_TCP packets to be used for the
number, simplifying the processing of those packets
15. It's also obvious that the change mask changes infrequently
could often be elided. In fact, one can do slightly better by
the last compressed packet (it can be at most 16 bytes so this isn'
much additional state) and checking to see if any of it (except the
checksum) has changed. If not, send a packet type that
`compressed TCP, same as last time' and a packet containing only
checksum and data. But, since the improvement is at most 25%, the
complexity and state doesn't seem justified. See appendix C
Jacobson [Page 8]
RFC 1144 Compressing TCP/IP Headers February 1990
TYPE_IP packet is an unmodified copy/16/ of the input packet
processing it doesn't change the compressor's state in any way
An UNCOMPRESSED_TCP packet is identical to the input packet except
IP protocol field (byte 9) is changed from `6' (protocol TCP) to
connection number. In addition, the state slot associated with
connection number is updated with a copy of the input packet's IP
TCP headers and the connection number is recorded as the last
sent on this serial line (for the C compression described below).
A COMPRESSED_TCP packet contains the data, if any, from the
packet but the IP and TCP headers are completely replaced with a new
compressed header. The connection state slot and last connection
are updated by the input packet exactly as for an UNCOMPRESSED_
packet
The compressor's decision procedure is
- If the packet is not protocol TCP, send it as TYPE_IP
- If the packet is an IP fragment (i.e., either the fragment
field is non-zero or the more fragments bit is set), send it
TYPE_IP./17/
- If any of the TCP control bits SYN, FIN or RST are set or if the
bit is clear, consider the packet uncompressible and send it
TYPE_IP./18/
----------------------------
16. It is not necessary (or desirable) to actually duplicate the
packet for any of the three output types. Note that the
cannot increase the size of a datagram. As the code in appendix
shows, the protocol can be implemented so all header modifications
made `in place'.
17. Only the first fragment contains the TCP header so the
offset check is necessary. The first fragment might contain a
TCP header and, thus, could be compressed. However the check for
complete TCP header adds quite a lot of code and, given the arguments
[6], it seems reasonable to send all IP fragments uncompressed
18. The ACK test is redundant since a standard
implementation must set ACK in all packets except for the initial
packet. However, the test costs nothing and avoids turning a
packet into a valid one
SYN packets are not compressed because only half of them contain a
ACK field and they usually contain a TCP option (the max. segment size
which the following packets don't. Thus the next packet would be
uncompressed because the TCP header length changed and sending the
as UNCOMPRESSED_TCP instead of TYPE_IP would buy nothing
The decision to not compress FIN packets is questionable.
the trick in appendix B.1, there is a free bit in the header that
be used to communicate the FIN flag. However, since connections tend
Jacobson [Page 9]
RFC 1144 Compressing TCP/IP Headers February 1990
If a packet makes it through the above checks, it will be sent as
UNCOMPRESSED_TCP or COMPRESSED_TCP
- If no connection state can be found that matches the packet's
and destination IP addresses and TCP ports, some state is
(which should probably be the least recently used) and
UNCOMPRESSED_TCP packet is sent
- If a connection state is found, the packet header it contains
checked against the current packet to make sure there were
unexpected changes. (E.g., that all the shaded fields in fig. 3
the same). The IP protocol, fragment offset, more fragments, SYN
FIN and RST fields were checked above and the source and
address and ports were checked as part of locating the state.
the remaining fields to check are protocol version, header length
type of service, don't fragment, time-to-live, data offset,
options (if any) and TCP options (if any). If any of these
differ between the two headers, an UNCOMPRESSED_TCP packet is sent
If all the `unchanging' fields match, an attempt is made to compress
current packet
- If the URG flag is set, the urgent data field is encoded (note
it may be zero) and the U bit is set in the change mask
Unfortunately, if URG is clear, the urgent data field must
checked against the previous packet and, if it changes,
UNCOMPRESSED_TCP packet is sent. (`Urgent data' shouldn't
when URG is clear but [11] doesn't require this.)
- The difference between the current and previous packet's
field is computed and, if non-zero, is encoded and the W bit is
in the change mask
- The difference between ack fields is computed. If the result
less than zero or greater than 2^16 - 1, an UNCOMPRESSED_TCP
is sent./19/ Otherwise, if the result is non-zero, it is
and the A bit is set in the change mask
- The difference between sequence number fields is computed. If
result is less than zero or greater than 2^16 - 1,
----------------------------
last for many packets, it seemed unreasonable to dedicate an entire
to a flag that would only appear once in the lifetime of the connection
19. The two tests can be combined into a single test of the
significant 16 bits of the difference being non-zero
Jacobson [Page 10]
RFC 1144 Compressing TCP/IP Headers February 1990
UNCOMPRESSED_TCP packet is sent./20/ Otherwise, if the result
non-zero, it is encoded and the S bit is set in the change mask
Once the U, W, A and S changes have been determined, the special-
encodings can be checked
- If U, S and W are set, the changes match one of the special-
encodings. Send an UNCOMPRESSED_TCP packet
- If only S is set, check if the change equals the amount of user
in the last packet. I.e., subtract the TCP and IP header
from the last packet's total length field and compare the result
the S change. If they're the same, set the change mask to SAWU (
special case for `unidirectional data transfer') and discard
encoded sequence number change (the decompressor can reconstruct
since it knows the last packet's total length and header length).
- If only S and A are set, check if they both changed by the
amount and that amount is the amount of user data in the
packet. If so, set the change mask to SWU (the special case
`echoed interactive' traffic) and discard the encoded changes
- If nothing changed, check if this packet has no user data (in
case it is probably a duplicate ack or window probe) or if
previous packet contained user data (which means this packet is
retransmission on a connection with no pipelining). In either
these cases, send an UNCOMPRESSED_TCP packet
Finally, the TCP/IP header on the outgoing packet is replaced with
compressed header
- The change in the packet ID is computed and, if not one,/21/
difference is encoded (note that it may be zero or negative) and
I bit is set in the change mask
- If the PUSH bit is set in the original datagram, the P bit is set
the change mask
- The TCP and IP headers of the packet are copied to the
state slot
----------------------------
20. A negative sequence number change probably indicates
retransmission. Since this may be due to the decompressor
dropped a packet, an uncompressed packet is sent to re-sync
decompressor (see sec. 4).
21. Note that the test here is against one, not zero. The packet ID
typically incremented by one for each packet sent so a change of zero
very unlikely. A change of one is likely: It occurs during any
when the originating system has activity on only one connection
Jacobson [Page 11]
RFC 1144 Compressing TCP/IP Headers February 1990
- The TCP and IP headers of the packet are discarded and a new
is prepended consisting of (in reverse order):
- the accumulated, encoded changes
- the TCP checksum (if the new header is being constructed `
place', the checksum may have been overwritten and will have
be taken from the header copy in the connection state or
in a temporary before the original header is discarded).
- the connection number (if different than the last one sent
this serial line). This also means that the the line's
connection sent must be set to the connection number and the
bit set in the change mask
- the change mask
At this point, the compressed TCP packet is passed to the framer
transmission
3.2.4 Decompressor
Because of the simplex communication model, processing at
decompressor is much simpler than at the compressor --- all
decisions have been made and the decompressor simply does what
compressor has told it to do
The decompressor is called with the incoming packet,/22/ the length
type of the packet and the compression state structure for the
serial line. A (possibly re-constructed) IP packet will be returned
The decompressor can receive four types of packet: the three
by the compressor and a TYPE_ERROR pseudo-packet generated when
receive framer detects an error./23/ The first step is a `switch'
the packet type
- If the packet is TYPE_ERROR or an unrecognized type, a `toss'
is set in the state to force COMPRESSED_TCP packets to be
until one with the C bit set or an UNCOMPRESSED_TCP packet arrives
Nothing (a null packet) is returned
----------------------------
22. It's assumed that link-level framing has been removed by this
and the packet and length do not include type or framing bytes
23. No data need be associated with a TYPE_ERROR packet. It exists
the receive framer can tell the decompressor that there may be a gap
the data stream. The decompressor uses this as a signal that
should be tossed until one arrives with an explicit connection number (
bit set). See the last part of sec. 4.1 for a discussion of why this
necessary
Jacobson [Page 12]
RFC 1144 Compressing TCP/IP Headers February 1990
- If the packet is TYPE_IP, an unmodified copy of it is returned
the state is not modified
- If the packet is UNCOMPRESSED_TCP, the state index from the
protocol field is checked./24/ If it's illegal, the toss flag
set and nothing is returned. Otherwise, the toss flag is cleared
the index is copied to the state's last connection received field,
copy of the input packet is made,/25/ the TCP protocol number
restored to the IP protocol field, the packet header is copied
the indicated state slot, then the packet copy is returned
If the packet was not handled above, it is COMPRESSED_TCP and a
TCP/IP header has to be synthesized from information in the packet
the last packet's header in the state slot. First, the explicit
implicit connection number is used to locate the state slot
- If the C bit is set in the change mask, the state index is checked
If it's illegal, the toss flag is set and nothing is returned
Otherwise, last connection received is set to the packet's
index and the toss flag is cleared
- If the C bit is clear and the toss flag is set, the packet
ignored and nothing is returned
At this point, last connection received is the index of the
state slot and the first byte(s) of the compressed packet (the
mask and, possibly, connection index) have been consumed. Since
TCP/IP header in the state slot must end up reflecting the newly
packet, it's simplest to apply the changes from the packet to
header then construct the output packet from that header
with the data from the input packet. (In the following description
`saved header' is used as an abbreviation for `the TCP/IP header
in the state slot'.)
- The next two bytes in the incoming packet are the TCP checksum
They are copied to the saved header
- If the P bit is set in the change mask, the TCP PUSH bit is set
the saved header. Otherwise the PUSH bit is cleared
----------------------------
24. State indices follow the C language convention and run from 0 to
- 1, where 0 < N <= 256 is the number of available state slots
25. As with the compressor, the code can be structured so no copies
done and all modifications are done in-place. However, since the
packet can be larger than the input packet, 128 bytes of free space
be left at the front of the input packet buffer to allow room to
the TCP/IP header
Jacobson [Page 13]
RFC 1144 Compressing TCP/IP Headers February 1990
- If the low order four bits (S, A, W and U) of the change mask
all set (the `unidirectional data' special case), the amount of
data in the last packet is calculated by subtracting the TCP and
header lengths from the IP total length in the saved header.
amount is then added to the TCP sequence number in the saved header
- If S, W and U are set and A is clear (the `terminal traffic'
case), the amount of user data in the last packet is calculated
added to both the TCP sequence number and ack fields in the
header
- Otherwise, the change mask bits are interpreted individually in
order that the compressor set them
- If the U bit is set, the TCP URG bit is set in the saved
and the next byte(s) of the incoming packet are decoded
stuffed into the TCP Urgent Pointer. If the U bit is clear,
TCP URG bit is cleared
- If the W bit is set, the next byte(s) of the incoming packet
decoded and added to the TCP window field of the saved header
- If the A bit is set, the next byte(s) of the incoming packet
decoded and added to the TCP ack field of the saved header
- If the S bit is set, the next byte(s) of the incoming packet
decoded and added to the TCP sequence number field of the
header
- If the I bit is set in the change mask, the next byte(s) of
incoming packet are decoded and added to the IP ID field of
saved packet. Otherwise, one is added to the IP ID
At this point, all the header information from the incoming packet
been consumed and only data remains. The length of the remaining
is added to the length of the saved IP and TCP headers and the result
put into the saved IP total length field. The saved IP header is now
to date so its checksum is recalculated and stored in the IP
field. Finally, an output datagram consisting of the saved
concatenated with the remaining incoming data is constructed
returned
4 Error
4.1 Error
In the author's experience, dialup connections are particularly prone
data errors. These errors interact with compression in two
ways
Jacobson [Page 14]
RFC 1144 Compressing TCP/IP Headers February 1990
First is the local effect of an error in a compressed packet. All
detection is based on redundancy yet compression has squeezed out
all the redundancy in the TCP and IP headers. In other words,
decompressor will happily turn random line noise into a perfectly
TCP/IP packet./26/ One could rely on the TCP checksum to
corrupted compressed packets but, unfortunately, some rather
errors will not be detected. For example, the TCP checksum will
not detect two single bit errors separated by 16 bits. For a V.32
signalling at 2400 baud with 4 bits/baud, any line hit lasting
than 400us. would corrupt 16 bits. According to [2], residential
line hits of up to 2ms. are likely
The correct way to deal with this problem is to provide for
detection at the framing level. Since the framing (at least in theory
can be tailored to the characteristics of a particular link,
detection can be as light or heavy-weight as appropriate for
link./27/ Since packet error detection is done at the framing level
the decompressor simply assumes that it will get an indication that
current packet was received with errors. (The decompressor
ignores (discards) a packet with errors. However, the indication
needed to prevent the error being propagated --- see below.)
The `discard erroneous packets' policy gives rise to the
interaction of errors and compression. Consider the
conversation
+-------------------------------------------+
|original | sent |received |reconstructed |
+---------+--------+---------+--------------+
| 1: A | 1: A | 1: A | 1: A |
| 2: BC | 1, BC | 1, BC | 2: BC |
| 4: DE | 2, DE | --- | --- |
| 6: F | 2, F | 2, F | 4: F |
| 7: GH | 1, GH | 1, GH | 5: GH |
+-------------------------------------------+
(Each entry above has the form `starting sequence number:data sent'
`?sequence number change,data sent'.) The first thing sent is
uncompressed packet, followed by four compressed packets. The
packet picks up an error and is discarded. To reconstruct the
packet, the receiver applies the sequence number change from
compressed packet to the sequence number of the last correctly
----------------------------
26. modulo the TCP checksum
27. While appropriate error detection is link dependent, the CCITT
used in [9] strikes an excellent balance between ease of computation
robust error detection for a large variety of links, particularly at
relatively small packet sizes needed for good interactive response
Thus, for the sake of interoperability, the framing in [9] should
used unless there is a truly compelling reason to do otherwise
Jacobson [Page 15]
RFC 1144 Compressing TCP/IP Headers February 1990
packet, packet two, and generates an incorrect sequence number
packet four. After the error, all reconstructed packets'
numbers will be in error, shifted down by the amount of data in
missing packet./28/
Without some sort of check, the preceding error would result in
receiver invisibly losing two bytes from the middle of the
(since the decompressor regenerates sequence numbers, the
containing F and GH arrive at the receiver's TCP with exactly
sequence numbers they would have had if the DE packet had
existed). Although some TCP conversations can survive missing data/29/
it is not a practice to be encouraged. Fortunately the TCP checksum
since it is a simple sum of the packet contents including the
numbers, detects 100% of these errors. E.g., the receiver's
checksum for the last two packets above always differs from the
checksum by two
Unfortunately, there is a way for the TCP checksum protection
above to fail if the changes in an incoming compressed packet
applied to the wrong conversation: Consider two active conversations C
and C2 and a packet from C1 followed by two packets from C2. Since
connection number doesn't change, it's omitted from the second C
packet. But, if the first C2 packet is received with a CRC error,
second C2 packet will mistakenly be considered the next packet in C1.
Since the C2 checksum is a random number with respect to the C1
numbers, there is at least a 2^-16 probability that this packet will
accepted by the C1 TCP receiver./30/ To prevent this, after a CRC
indication from the framer the receiver discards packets until
receives either a COMPRESSED_TCP packet with the C bit set or
UNCOMPRESSED_TCP packet. I.e., packets are discarded until the
gets an explicit connection number
To summarize this section, there are two different types of errors
per-packet corruption and per-conversation loss-of-sync. The first
is detected at the decompressor from a link-level CRC error, the
at the TCP receiver from a (guaranteed) invalid TCP checksum.
combination of these two independent mechanisms ensures that
packets are discarded
----------------------------
28. This is an example of a generic problem with differential or
encodings known as `losing DC'.
29. Many system managers claim that holes in an NNTP stream are
valuable than the data
30. With worst-case traffic, this probability translates to
undetected error every three hours over a 9600 baud line with a 30%
error rate).
Jacobson [Page 16]
RFC 1144 Compressing TCP/IP Headers February 1990
4.2 Error
The previous section noted that after a CRC error the decompressor
introduce TCP checksum errors in every uncompressed packet.
the checksum errors prevent data stream corruption, the TCP
won't be terribly useful until the decompressor again generates
packets. How can this be forced to happen
The decompressor generates invalid packets because its state (the
`last packet header') disagrees with the compressor's state.
UNCOMPRESSED_TCP packet will correct the decompressor's state.
error recovery amounts to forcing an uncompressed packet out of
compressor whenever the decompressor is (or might be) confused
The first thought is to take advantage of the full duplex
link and have the decompressor send something to the
requesting an uncompressed packet. This is clearly undesirable since
constrains the topology more than the minimum suggested in sec. 2
requires that a great deal of protocol be added to both the
and compressor. A little thought convinces one that this alternative
not only undesirable, it simply won't work: Compressed packets
small and it's likely that a line hit will so completely obliterate
that the decompressor will get nothing at all. Thus packets
reconstructed incorrectly (because of the missing compressed packet)
only the TCP end points, not the decompressor, know that the packets
incorrect
But the TCP end points know about the error and TCP is a
protocol designed to run over unreliable media. This means the
points must eventually take some sort of error recovery action
there's an obvious trigger for the compressor to resync
decompressor: send uncompressed packets whenever TCP is doing
recovery
But how does the compressor recognize TCP error recovery? Consider
schematic TCP data transfer of fig. 6. The confused decompressor
in the forward (data transfer) half of the TCP conversation.
receiving TCP discards packets rather than acking them (because of
checksum errors), the sending TCP eventually times out and retransmits
packet, and the forward path compressor finds that the
between the sequence number in the retransmitted packet and the
number in the last packet seen is either negative (if there
multiple packets in transit) or zero (one packet in transit). The
case is detected in the compression step that computes sequence
differences. The second case is detected in the step that checks
`special case' encodings but needs an additional test: It's
common for an interactive conversation to send a dataless ack
followed by a data packet. The ack and data packet will have the
sequence numbers yet the data packet is not a retransmission.
prevent sending an unnecessary uncompressed packet, the length of
previous packet should be checked and, if it contained data, a
Jacobson [Page 17]
RFC 1144 Compressing TCP/IP Headers February 1990
sequence number change must indicate a retransmission
A confused decompressor in the reverse (ack) half of the conversation
as easy to detect (fig. 7): The sending TCP discards acks (
they contain checksum errors), eventually times out, then
some packet. The receiving TCP thus gets a duplicate packet and
generate an ack for the next expected sequence number[11, p. 69].
ack will be a duplicate of the last ack the receiver generated so
reverse-path compressor will find no ack, seq number, window or
change. If this happens for a packet that contains no data,
compressor assumes it is a duplicate ack sent in response to
retransmit and sends an UNCOMPRESSED_TCP packet./31/
5 Configurable parameters and
5.1 Compression
There are two configuration parameters associated with
compression: Whether or not compressed packets should be sent on
particular line and, if so, how many state slots (saved packet headers
to reserve. There is also one link-level configuration parameter,
maximum packet size or MTU, and one front-end configuration parameter
data compression, that interact with header compression.
configuration is discussed in this section. MTU and data
are discussed in the next two sections
There are some hosts (e.g., low end PCs) which may not have
processor or memory resources to implement this compression. There
also rare link or application characteristics that make
compression unnecessary or undesirable. And there are many
SLIP links that do not currently use this style of header compression
For the sake of interoperability, serial line IP drivers that
header compression should include some sort of user configurable flag
disable compression (see appendix B.2)./32/
If compression is enabled, the compressor must be sure to never send
connection id (state index) that will be dropped by the decompressor
E.g., a black hole is created if the decompressor has sixteen slots
----------------------------
31. The packet could be a zero-window probe rather than a
ack but window probes should be infrequent and it does no harm to
them uncompressed
32. The PPP protocol in [9] allows the end points to
compression so there is no interoperability problem. However,
should still be a provision for the system manager at each end
control whether compression is negotiated on or off. And, obviously
compression should default to `off' until it has been negotiated `on'.
Jacobson [Page 18]
RFC 1144 Compressing TCP/IP Headers February 1990
the compressor uses twenty./33/ Also, if the compressor is allowed
few slots, the LRU allocator will thrash and most packets will be
as UNCOMPRESSED_TCP. Too many slots and memory is wasted
Experimenting with different sizes over the past year, the author
found that eight slots will thrash (i.e., the performance degradation
noticeable) when many windows on a multi-window workstation
simultaneously in use or the workstation is being used as a gateway
three or more other machines. Sixteen slots were never observed
thrash. (This may simply be because a 9600 bps line split more than 16
ways is already so overloaded that the additional degradation
round-robbining slots is negligible.)
Each slot must be large enough to hold a maximum length TCP/IP header
128 bytes/34/ so 16 slots occupy 2KB of memory. In these days of 4
RAM chips, 2KB seems so little memory that the author recommends
following configuration rules
(1) If the framing protocol does not allow negotiation, the
and decompressor should provide sixteen slots, zero through fifteen
(2) If the framing protocol allows negotiation, any mutually
number of slots from 1 to 256 should be negotiable./35/ If
of slots is not negotiated, or until it is negotiated, both
should assume sixteen
(3) If you have complete control of all the machines at both ends
every link and none of them will ever be used to talk to
outside of your control, you are free to configure them however
please, ignoring the above. However, when your little eastern-
dictatorship collapses (as they all eventually seem to), be
that a large, vocal, and not particularly forgiving
community will take great delight in pointing out to anyone
----------------------------
33. Strictly speaking, there's no reason why the connection id
be treated as an array index. If the decompressor's states were kept
a hash table or other associative structure, the connection id would
a key, not an index, and performance with too few decompressor
would only degrade enormously rather than failing altogether. However
an associative structure is substantially more costly in code and
time and, given the small per-slot cost (128 bytes of memory), it
reasonable to design for slot arrays at the decompressor and
(possibly implicit) communication of the array size
34. The maximum header length, fixed by the protocol design, is 64
bytes of IP and 64 bytes of TCP
35. Allowing only one slot may make the compressor code more complex
Implementations should avoid offering one slot if possible
compressor implementations may disable compression if only one slot
negotiated
Jacobson [Page 19]
RFC 1144 Compressing TCP/IP Headers February 1990
to listen that you have misconfigured your systems and are
interoperable
5.2 Choosing a maximum transmission
From the discussion in sec. 2, it seems desirable to limit the
packet size (MTU) on any line where there might be interactive
and multiple active connections (to maintain good interactive
between the different connections competing for the line). The
question is `how much does this hurt throughput?' It doesn't
Figure 8 shows how user data throughput/36/ scales with MTU with (
line) and without (dashed line) header compression. The dotted
show what MTU corresponds to a 200 ms packet time at 2400, 9600
19,200 bps. Note that with header compression even a 2400 bps line
be responsive yet have reasonable throughput (83%)./37/
Figure 9 shows how line efficiency scales with increasing line speed
assuming that a 200ms. MTU is always chosen./38/ The knee in
performance curve is around 2400 bps. Below this, efficiency
sensitive to small changes in speed (or MTU since the two are
related) and good efficiency comes at the expense of good response
Above 2400bps the curve is flat and efficiency is relatively
of speed or MTU. In other words, it is possible to have both
response and high line efficiency
To illustrate, note that for a 9600 bps line with header
there is essentially no benefit in increasing the MTU beyond 200 bytes
If the MTU is increased to 576, the average delay increases by 188%
while throughput only improves by 3% (from 96 to 99%).
----------------------------
36. The vertical axis is in percent of line speed. E.g., `95'
that 95% of the line bandwidth is going to user data or, in other words
the user would see a data transfer rate of 9120 bps on a 9600 bps line
Four bytes of link-level (framer) encapsulation in addition to
TCP/IP or compressed header were included when calculating the
throughput. The 200 ms packet times were computed assuming
asynchronous line using 10 bits per character (8 data bits, 1 start, 1
stop, no parity).
37. However, the 40 byte TCP MSS required for a 2400 bps line
stress-test your TCP implementation
38. For a typical async line, a 200ms. MTU is simply .02 times the
speed in bits per second
Jacobson [Page 20]
RFC 1144 Compressing TCP/IP Headers February 1990
5.3 Interaction with data
Since the early 1980's, fast, effective, data compression
such as Lempel-Ziv[7] and programs that embody them, such as
compress program shipped with Berkeley Unix, have become
available. When using low speed or long haul lines, it has
common practice to compress data before sending it. For
connections, this compression is often done in the modems,
of the communicating hosts. Some interesting issues would seem to be
(1) Given a good data compressor, is there any need for
compression? (2) Does header compression interact with
compression? (3) Should data be compressed before or after
compression?/39/
To investigate (1), Lempel-Ziv compression was done on a trace of 446
TCP/IP packets taken from the user's side of a typical
conversation. Since the packets resulted from typing, almost
contained only one data byte plus 40 bytes of header. I.e., the
essentially measured L-Z compression of TCP/IP headers. The
ratio (the ratio of uncompressed to compressed data) was 2.6. In
words, the average header was reduced from 40 to 16 bytes. While
is good compression, it is far from the 5 bytes of header needed
good interactive response and far from the 3 bytes of header (
compression ratio of 13.3) that header compression yielded on the
packet trace
The second and third questions are more complex. To investigate them
several packet traces from FTP file transfers were analyzed/40/ with
without header compression and with and without L-Z compression.
L-Z compression was tried at two places in the outgoing data
(fig. 10): (1) just before the data was handed to TCP
encapsulation (simulating compression done at the `application' level
and (2) after the data was encapsulated (simulating compression done
the modem). Table 1 summarizes the results for a 78,776 byte ASCII
file (the Unix csh.1 manual entry)/41/ transferred using the
of the previous section (256 byte MTU or 216 byte MSS; 368
total). Compression ratios for the following ten tests are
(reading left to right and top to bottom):
----------------------------
39. The answers, for those who wish to skip the remainder of
section, are `yes', `no' and `either', respectively
40. The data volume from user side of a telnet is too small to
from data compression and can be adversely affected by the delay
compression algorithms (necessarily) add. The statistics and volume
the computer side of a telnet are similar to an (ASCII) FTP so
results should apply to either
41. The ten experiments described were each done on ten ASCII
(four long e-mail messages, three Unix C source files and three
manual entries). The results were remarkably similar for
files and the general conclusions reached below apply to all ten files
Jacobson [Page 21]
RFC 1144 Compressing TCP/IP Headers February 1990
- data file (no compression or encapsulation
- data -> L--Z
- data -> TCP/IP
- data -> L--Z -> TCP/
- data -> TCP/IP -> L--
- data -> L--Z -> TCP/IP -> L--
- data -> TCP/IP -> Hdr. Compress
- data -> L--Z -> TCP/IP -> Hdr. Compress
- data -> TCP/IP -> Hdr. Compress. -> L--
- data -> L--Z -> TCP/IP -> Hdr. Compress. -> L--
+-----------------------------------------------------+
| | No data | L--Z | L--Z | L--Z |
| |compress. |on data |on wire | on both |
+--------------+----------+--------+--------+---------+
| Raw Data | 1.00 | 2.44 | ---- | ---- |
| + TCP Encap. | 0.83 | 2.03 | 1.97 | 1.58 |
| w/Hdr Comp. | 0.98 | 2.39 | 2.26 | 1.66 |
+-----------------------------------------------------+
Table 1: ASCII Text File Compression
The first column of table 1 says the data expands by 19% (`compresses
by .83) when encapsulated in TCP/IP and by 2% when encapsulated
header compressed TCP/IP./42/ The first row says L--Z compression
quite effective on this data, shrinking it to less than half
original size. Column four illustrates the well-known fact that it is
mistake to L--Z compress already compressed data. The
information is in rows two and three of columns two and three.
columns say that the benefit of data compression overwhelms the cost
encapsulation, even for straight TCP/IP. They also say that it
slightly better to compress the data before encapsulating it rather
compressing at the framing/modem level. The differences however
----------------------------
42. This is what would be expected from the relative header sizes
256/216 for TCP/IP and 219/216 for header compression
Jacobson [Page 22]
RFC 1144 Compressing TCP/IP Headers February 1990
small --- 3% and 6%, respectively, for the TCP/IP and header
encapsulations./43/
Table 2 shows the same experiment for a 122,880 byte binary file (
Sun-3 ps executable). Although the raw data doesn't compress nearly
well, the results are qualitatively the same as for the ASCII data.
one significant change is in row two: It is about 3% better to
the data in the modem rather than at the source if doing TCP/
encapsulation (apparently, Sun binaries and TCP/IP headers have
statistics). However, with header compression (row three) the
were similar to the ASCII data --- it's about 3% worse to compress
the modem rather than the source./44/
+-----------------------------------------------------+
| | No data | L--Z | L--Z | L--Z |
| |compress. |on data |on wire | on both |
+--------------+----------+--------+--------+---------+
| Raw Data | 1.00 | 1.72 | ---- | ---- |
| + TCP Encap. | 0.83 | 1.43 | 1.48 | 1.21 |
| w/Hdr Comp. | 0.98 | 1.69 | 1.64 | 1.28 |
+-----------------------------------------------------+
Table 2: Binary File Compression
6 Performance
An implementation goal of compression code was to arrive at
simple enough to run at ISDN speeds (64Kbps) on a typical 1989
----------------------------
43. The differences are due to the wildly different byte patterns
TCP/IP datagrams and ASCII text. Any compression scheme with
underlying, Markov source model, such as Lempel-Ziv, will do worse
radically different sources are interleaved. If the
proportions of the two sources are changed, i.e., the MTU is increased
the performance difference between the two compressor
decreases. However, the rate of decrease is very slow ---
the MTU by 400% (256 to 1024) only changed the difference between
data and modem L--Z choices from 2.5% to 1.3%.
44. There are other good reasons to compress at the source: Far
packets have to be encapsulated and far fewer characters have to be
to the modem. The author suspects that the `compress data in the modem
alternative should be avoided except when faced with an intractable
vendor proprietary operating system
Jacobson [Page 23]
RFC 1144 Compressing TCP/IP Headers February 1990
+---------------------------------------+
| | Average per-packet |
| Machine | processing time (us.) |
| | |
| | Compress | Decompress |
+---------------+----------+------------+
|Sparcstation-1 | 24 | 18 |
| Sun 4/260 | 46 | 20 |
| Sun 3/60 | 90 | 90 |
| Sun 3/50 | 130 | 150 |
| HP9000/370 | 42 | 33 |
| HP9000/360 | 68 | 70 |
| DEC 3100 | 27 | 25 |
| Vax 780 | 430 | 300 |
| Vax 750 | 800 | 500 |
| CCI Tahoe | 110 | 140 |
+---------------------------------------+
Table 3: Compression code
workstation. 64Kbps is a byte every 122us so 120us was (arbitrarily
picked as the target compression/decompression time./45/
As part of the compression code development, a trace-driven
was developed. This was initially used to compare different
protocol choices then later to test the code on different
architectures and do regression tests after performance `improvements'.
A small modification of this test program resulted in a
measurement tool./46/ Table 3 shows the result of timing
compression code on all the 