Connected: An Internet Encyclopedia
RFC 1144 - 3.2.3 Compressor processing
Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1144
Up: 3 The compression algorithm
Up: 3.2 The ugly details
Prev: 3.2.2 Compressed packet format
Next: 3.2.4 Decompressor processing

3.2.3 Compressor processing

The compressor is called with the IP packet to be processed and the compression state structure for the outgoing serial line. It returns a packet ready for final framing and the link level `type' of that packet.

As the last section noted, the compressor converts every input packet into either a TYPE_IP, UNCOMPRESSED_TCP or COMPRESSED_TCP packet. A

TYPE_IP packet is an unmodified copy/16/ of the input packet and processing it doesn't change the compressor's state in any way.

An UNCOMPRESSED_TCP packet is identical to the input packet except the IP protocol field (byte 9) is changed from `6' (protocol TCP) to a connection number. In addition, the state slot associated with the connection number is updated with a copy of the input packet's IP and TCP headers and the connection number is recorded as the last connection sent on this serial line (for the C compression described below).

A COMPRESSED_TCP packet contains the data, if any, from the original packet but the IP and TCP headers are completely replaced with a new, compressed header. The connection state slot and last connection sent are updated by the input packet exactly as for an UNCOMPRESSED_TCP packet.

The compressor's decision procedure is:

If a packet makes it through the above checks, it will be sent as either UNCOMPRESSED_TCP or COMPRESSED_TCP: If all the `unchanging' fields match, an attempt is made to compress the current packet: Once the U, W, A and S changes have been determined, the special-case encodings can be checked: Finally, the TCP/IP header on the outgoing packet is replaced with a compressed header:

At this point, the compressed TCP packet is passed to the framer for transmission.


16. It is not necessary (or desirable) to actually duplicate the input packet for any of the three output types. Note that the compressor cannot increase the size of a datagram. As the code in appendix A shows, the protocol can be implemented so all header modifications are made `in place'.
17. Only the first fragment contains the TCP header so the fragment offset check is necessary. The first fragment might contain a complete TCP header and, thus, could be compressed. However the check for a complete TCP header adds quite a lot of code and, given the arguments in [6], it seems reasonable to send all IP fragments uncompressed.
18. The ACK test is redundant since a standard conforming implementation must set ACK in all packets except for the initial SYN packet. However, the test costs nothing and avoids turning a bogus packet into a valid one. SYN packets are not compressed because only half of them contain a valid 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 sent uncompressed because the TCP header length changed and sending the SYN as UNCOMPRESSED_TCP instead of TYPE_IP would buy nothing. The decision to not compress FIN packets is questionable. Discounting the trick in appendix B.1, there is a free bit in the header that could be used to communicate the FIN flag. However, since connections tend to last for many packets, it seemed unreasonable to dedicate an entire bit 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 most significant 16 bits of the difference being non-zero.
20. A negative sequence number change probably indicates a retransmission. Since this may be due to the decompressor having dropped a packet, an uncompressed packet is sent to re-sync the decompressor (see sec. 4).
21. Note that the test here is against one, not zero. The packet ID is typically incremented by one for each packet sent so a change of zero is very unlikely. A change of one is likely: It occurs during any period when the originating system has activity on only one connection.


Next: 3.2.4 Decompressor processing

Connected: An Internet Encyclopedia
RFC 1144 - 3.2.3 Compressor processing