Skip to main content

1. Introduction

There are several reasons to do header compression on low- or medium-speed links. Header compression can

  • Improve interactive response time

    For very low-speed links, echoing of characters may take longer than 100-200 ms because of the time required to transmit large headers. 100-200 ms is the maximum time people can tolerate without feeling that the system is sluggish.

  • Allow using small packets for bulk data with good line efficiency

    This is important when interactive (for example Telnet) and bulk traffic (for example FTP) is mixed because the bulk data should be carried in small packets to decrease the waiting time when a packet with interactive data is caught behind a bulk data packet.

    Using small packet sizes for the FTP traffic in this case is a global solution to a local problem. It will increase the load on the network as it has to deal with many small packets. A better solution might be to locally fragment the large packets over the slow link.

  • Allow using small packets for delay sensitive low data-rate traffic

    For such applications, for example voice, the time to fill a packet with data is significant if packets are large. To get low end-to-end delay small packets are preferred. Without header compression, the smallest possible IPv6/UDP headers (48 octets) consume 19.2 kbit/s with a packet rate of 50 packets/s. 50 packets/s is equivalent to having 20 ms worth of voice samples in each packet. IPv4/UDP headers consumes 11.2 kbit/s at 50 packets/s. Tunneling or routing headers, for example to support mobility, will increase the bandwidth consumed by headers by 10-20 kbit/s. This should be compared with the bandwidth required for the actual sound samples, for example 13 kbit/s with GSM encoding. Header compression can reduce the bandwidth needed for headers significantly, in the example to about 1.7 kbit/s. This enables higher quality voice transmission over 14.4 and 28.8 kbit/s modems.

  • Decrease header overhead.

    A common size of TCP segments for bulk transfers over medium-speed links is 512 octets today. When TCP segments are tunneled, for example because Mobile IP is used, the IPv6/IPv6/TCP header is 100

  octets.  Header compression will decrease the header overhead for
  IPv6/TCP from 19.5 per cent to less than 1 per cent, and for
  tunneled IPv4/TCP from 11.7 to less than 1 per cent. This is a
  significant gain for line-speeds as high as a few Mbit/s.

  The IPv6 specification prescribes path MTU discovery, so with IPv6
  bulk TCP transfers should use segments larger than 512 octets when
  possible.  Still, with 1400 octet segments (RFC 894 Ethernet
  encapsulation allows 1500 octet payloads, of which 100 octets are
  used for IP headers), header compression reduces IPv6 header
  overhead from 7.1% to 0.4%.

  • Reduce packet loss rate over lossy links.

    Because fewer bits are sent per packet, the packet loss rate will be lower for a given bit-error rate. This results in higher throughput for TCP as the sending window can open up more between losses, and in fewer lost packets for UDP.

The mechanisms described here are intended for a point-to-point link. However, care has been taken to allow extensions for multi-access links and multicast.

Headers that can be compressed include TCP, UDP, IPv4, and IPv6 base and extension headers. For TCP packets, the mechanisms of Van Jacobson [RFC-1144] are used to recover from loss. Two additional mechanisms that increase the efficiency of VJ header compression over lossy links are also described. For non-TCP packets, compression slow-start and periodic header refreshes allow minimal periods of packet discard after loss of a header that changes the context. There are hooks for adding header compression schemes on top of UDP, for example compression of RTP headers.

Header compression relies on many fields being constant or changing seldomly in consecutive packets belonging to the same packet stream. Fields that do not change between packets need not be transmitted at all. Fields that change often with small and/or predictable values, e.g., TCP sequence numbers, can be encoded incrementally so that the number of bits needed for these fields decrease significantly. Only fields that change often and randomly, e.g., checksums or authentication data, need to be transmitted in every header.

The general principle of header compression is to occasionally send a packet with a full header; subsequent compressed headers refer to the context established by the full header and may contain incremental changes to the context.

This header compression scheme does not require that all packets in the same stream passes over the compressed link. However, for TCP streams the difference between subsequent headers can become more irregular and the compression rate can decrease. Neither is it required that corresponding TCP data and acknowledgment packets traverse the link in opposite directions.

This header compression scheme is useful on first-hop or last-hop links as well as links in the middle of the network. When many packet streams (several hundred) traverse the link, a phenomenon that could be called CID thrashing could occur, where headers seldom can be matched with an existing context and have to be sent uncompressed or as full headers. It is up to an implementation to use techniques such as hysteresis to ensure that the packet streams that give the highest compression rates keep their context. Such techniques are more likely to be needed in the middle of the network.