RoHC & RoHCv2

Its been a while since I blogged about Robust Header Compression (RoHC). You can see the old posts here and here. Here is an example message showing the header compression information.

RoHCv2 is also available as specified in RFC 5225.

On Header Compression

Was doing some digging into pre-ROHC compression techniques and here they are:

Van Jacobson header compression (VJHC) (RFC 1144) is based on delta coding. The differences between two packet headers are referred to as the “delta”. Instead of transmitting the entire header, VJHC transmits only the delta. This approach achieves high compression. On the downside, it introduces vulnerability. If only one delta coded header is corrupted, all the following packets are erroneous. To recover from these errors and re–establish the current base header, VJHC sends all TCP re–transmissions uncompressed. Thus, VJHC does not require any signaling between compressor and decompressor. The disadvantage is the sensitivity to error–prone links. The Van Jacobson compression scheme was developed to increase the performance of IP/TCP flows over low bandwidth links such as PSTN. It does not even support compression of IP/UDP flows since at that time UDP traffic was very low. This scheme uses delta compression, sending only the difference in the value of the changing fields, to minimize the number of bits sent. It achieves compression from 40 bytes to on an average 4 bytes. It relies on the TCP recovery mechanism to recover from errors in the context due to bit errors and residual errors due to packet loss on the link. This scheme is obviously unsuitable for wireless links and multimedia applications.

Robustness at the cost of less compression was introduced by Perkins and Mutka. In “Dependency Removal for Transport Protocol Header Compression over Noisy Channels,” The delta–coding for the adjacent packets has been replaced by a reference frame. Several consecutive packets are aggregated to a frame. The first packet of a frame is sent uncompressed and the following packets use delta coding with respect to the first (uncompressed) packet in the frame. Clearly, the differences to packets at the end of a frame are larger than for those at the beginning. The compression gain is thus limited (and lower than for VJHC). The advantage of this approach is the usage of shorter delta coding ranges. Corrupted packets do not necessarily lead to the loss of synchronization. This is a clear advantage over VJHC.

IP Header Compression (IPHC) provides a number of extensions to VJHC. The most important extensions are support for UDP, IPv6, and additional TCP features (RFC 2507). With the explicit support of UDP come additional features, such as multicast. Nevertheless, support for RTP is still not given which makes the scheme unsuitable for many multimedia applications. Similar to VJHC, IPHC relies on the change of header fields as well as on the derivation of header field contents. The encoding also employs the delta–scheme, transmitting only the changes in the header fields.

The Compressed Real Time Protocol (CRTP) scheme presented in RFC2508 compresses the 40 bytes header of IP to 4 bytes if the UDP checksum is enabled, or to 2 bytes if it is not. This is possible by compressing the RTP/UDP/IP headers together, similar to the VJHC approach. With the characteristics of the RTP protocol, the changes for the RTP header fields become partially predictable. In addition, changes in some fields are constant over long periods of time. Thus, the expected change in these fields can be implied without even transmitting the differences. These implied fields are also referred to as first order changes. They are stored with the general context for each specific connection. The differences within fields that have to be compressed are referred to as second order differences. An example for these are video frame skips. Video frames are generally transmitted every 40 ms. In case a frame cannot be encoded (e.g., due to lack of processing power or because of a slower play-out ratio), the implied time no longer is accurate. Therefore, the new first order is set to the second order and the connection context is updated. CRTP cannot use a repair mechanism as VJHC does because UDP/RTP are unidirectional protocols without retransmissions.

RObust Checksum–based COmpression (ROCCO) is a refinement of CRTP. ROCCO includes a checksum over the original (uncompressed) header in the compressed header. The checksum facilitates local recovery of the synchronization. In addition, ROCCO incorporates compression profiles (tailored for specific applications, e.g., audio or video streaming) and has a code with hints on the change of header fields in the compressed header. These mechanisms improve the header compression performance, especially for highly error–prone links and long round trip times

ROHC, compressing IP headers over air interface

In an All-IP network, when IP packets are transmitted over the air, it would make more sense to strip down the headers as headers could be as big as the data being transmitted and these headers are overhead wasting the precious air resource. To help compress these headers, RObust Header Compression was standardised. Infact ROHC is not the only header compression scheme and i will post a bit more information in my future posts on which scehemes are available and why ROHC is used.

The diagram above shows the basic ROHC principle. It shows that ROHC compresseor is used before the data is sent over the air and decompressor at the receiving end adds the uncompressed headers back to the received packets. As expected, ROHC only works if both the ends have ROHC protocol.

A typical header compression is shown in the diagram above.

More information is available at the 3G4G website.