scope:

Introduction

For many types of networks, reducing the deployment and operational costs by improving the usage of the bandwidth resources is of vital importance. Header compression over a link is possible because some of the information carried within the header of a packet becomes compressible between packets belonging to the same flow.

For links where the overhead of the IP header(s) is problematic, the total size of the header may be sig. Applications transferring data carried within RTP [RFC3550] will then, in addition to link-layer framing, have an IPv4 [RFC0791] header (20 octets), a UDP [RFC0768] header (8 octets), and an RTP header (12 octets), for a total of 40 octets. With IPv6 [RFC2460], the IPv6 header is 40 octets for a total of 60 octets. Applications transferring data using TCP [RFC0793] will have 20 octets for the transport header, for a total size of 40 octets for IPv4 and 60 octets for IPv6.

The relative gain for specific flows (or applications) depends on the size of the payload used in each packet. For applications such as Voice over IP, where the size of the payload containing coded speech can be as small as 15-20 octets, this gain will be quite significant. Similarly, relative gains for TCP flows carrying large payloads (such as file transfers) will be less than for flows carrying smaller payloads (such as application signaling, e.g., session initiation).

As more and more wireless link technologies are being deployed to carry IP traffic, care must be taken to address the specific characteristics of these technologies within the header compression algorithms. Legacy header compression schemes, such as those defined in [RFC2507] and [RFC2508], have been shown to perform inadequately over links where both the lossy behavior and the round-trip times are non-negligible, such as those observed, for example, in wireless links and IP tunnels.

In addition, a header compression scheme should handle the often nontrivial residual errors, i.e., where the lower layer may pass a packet that contains undetected bit errors to the decompressor. It should also handle loss and reordering before the compression point, as well as on the link between the compression and decompression points [RFC4224].

The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.

RFC 3095 [RFC3095] defines the ROHC framework along with an initial set of compression profiles. To improve and simplify the specification, the framework and the profiles' parts have been split into separate documents. This document explicitly defines the ROHC framework, but it does not modify or update the definition of the framework specified by RFC 3095; both documents can be used independently of each other. This also implies that implementations based on either definition will be compatible and interoperable with each other. However, it is the intent to let this specification replace RFC 3095 as the base specification for all profiles defined in the future.

This document fixes one interoperability issue that was erroneously introduced in RFC 4995. The fix for this issue is located in Section 5.2.4.1 and clarifies the interpretation of the Size field in ROHC feedback.