Skip to main content

10. Low-loss header compression for TCP

  1. Low-loss header compression for TCP

Since fewer bits are transmitted per packet with header compression, the packet loss rate is lower with header compression than without, for a fixed bit-error rate. This is beneficial for links with high bit-error rates such as wireless links.

However, since TCP headers are compressed using differential encoding, a single lost TCP segment can ruin an entire TCP sending window because the context is not incremented properly at the decompressor. Subsequent headers will therefore be decompressed to be different than before compression and discarded by the TCP receiver because the TCP checksum fails.

A TCP connection in the wide area where the last hop is over a medium-speed lossy link, for example a wireless LAN, will then have poor performance with traditional header compression because the delay-bandwidth product is relatively large and the bit-error rate relatively high. For a 2 Mbit/s wireless LAN and an end-to-end RTT of 200 ms, the delay-bandwidth product is 50 kbyte. That is equivalent to about 97 512-octet segments with compressed headers. Each loss can thus be multiplied by a factor of 100.

This section describes two simple mechanisms for quick repair of the context. With these mechanisms header compression will improve TCP throughput over lossy links as well as links with low bit-error rates.

10.1. The "twice" algorithm

The decompressor may compute the TCP checksum to determine if its context is not updated properly. If the checksum fails, the error is assumed to be caused by a lost segment that did not update the context properly. The delta of the current segment is then added to the context again on the assumption that the lost segment contained the same delta as the current. By decompressing and computing the TCP checksum again, the decompressor checks if the repair succeeded or if the delta should be applied once more.

Analysis of traces of various TCP bulk transfers show that applying the delta of the current segment one or two times will repair the context for between 83 and 99 per cent of all single-segment losses in the data stream. For the acknowledgment stream, the success rate is smaller due to the delayed ack mechanism of TCP. The "twice" mechanism repairs the context for 53 to 99 per cent of the losses in the acknowledgment stream. A sophisticated implementation of this idea would determine whether the TCP stream is an acknowledgment or data stream and determine the segment size by observing the stream of full and compressed headers. Trying deltas that are small multiples of the segment size will result in even higher rates of successful repairs for acknowledgment streams.

10.2. Header Requests

The relatively low success rate for the "twice" algorithm for TCP acknowledgment streams calls for an additional mechanism for repairing the context at the decompressor. When the decompressor fails to repair the context after a loss, the decompressor may optionally request a full header from the compressor. This is possible on links where the decompressor can identify the compressor and send packets to it.

On such links, a decompressor may send a CONTEXT_STATE packet back to the compressor to indicate that one or more contexts are invalid. A decompressor SHOULD NOT transmit a CONTEXT_STATE packet every time a compressed packet refers to an invalid context, but instead should limit the rate of transmission of CONTEXT_STATE packets to avoid flooding the reverse channel. A CONTEXT_STATE packet can indicate that several contexts are out of date, this technique SHOULD be used instead of sending several separate packets. The following diagram shows the format of a CONTEXT_STATE packet.

                       0   1   2   3   4   5   6   7
                    +---+---+---+---+---+---+---+---+
                    |     TCP header request = 3    |
                    +---+---+---+---+---+---+---+---+
                    |           CID count           |
                    +---+---+---+---+---+---+---+---+
                    |              CID              |
                    +---+---+---+---+---+---+---+---+
                    |              CID              |
                    +---+---+---+---+---+---+---+---+
                                           ...
                    +---+---+---+---+---+---+---+---+
                    |              CID              |
                    +---+---+---+---+---+---+---+---+

The first octet is a type code to allow the CONTEXT_STATE packet type to be shared for other compression protocols that are (see [CRTP]) or may be defined in parallel with this one. When used for TCP header requests the type code has the value 3, and the remainder of the packet is a sequence of CIDs preceded by a one-octet count of the number of CIDs.

On receipt of a CONTEXT_STATE packet, the compressor MUST mark the CIDs invalid to ensure that the next packet emitted in those packet streams are FULL_HEADER or COMPRESSED_TCP_NODELTA packets.

Header requests are an optimization, so loss of a CONTEXT_STATE packet does not affect the correct operation of TCP header compression. When a CONTEXT_STATE packet is lost, eventually a new one will be transmitted or TCP will timeout and retransmit. The big advantage of using header requests is that TCP acknowledgment streams can be repaired after a roundtrip-time over the lossy link. This will typically avoid a TCP timeout and unnecessary retransmissions. The lower packet loss rate due to smaller packets will then result in higher throughput because the TCP window can grow larger between losses.

Last updated on