RFC 3096

RFC 3096: Requirements for robust IP/UDP/RTP header compression 💖

okay bestie, this one is the requirements doc for ROHC (Robust Header Compression). it's an Informational RFC, so it's giving "here's what we're aiming for" 🧚 It was written by M. Degermark, Editor, from the University of Arizona, and it's dated July 2001. The header doesn't list any RFCs it obsoletes or updates, so no drama there ✨

Network Working Group, Request for Comments 3096, Category: Informational, July 2001 🎀

Status of This Memo 🌸

okay so this memo is just giving information to the Internet community. it does NOT specify an Internet standard of any kind 💅 and distribution of this memo is unlimited, so share it with everyone 🦋

Copyright Notice 🌈

Copyright (C) The Internet Society (2001). All Rights Reserved. ✨

Abstract 📝

this doc holds the requirements for robust IP/UDP/RTP header compression, which the ROHC (Robust Header Compression) WG is going to build. it's based on the ROHC charter, discussions in the WG, the 3GPP document "3GPP TR 23.922", version 1.0.0 of October 1999, and contributions from 3G.IP 🫶

1. Introduction 🦋

the ROHC WG's whole goal is to develop header compression schemes that perform well over links with high error rates and long link round trip times. the schemes MUST perform well for cellular links built using technologies like WCDMA, EDGE, and CDMA-2000. however, the schemes SHOULD also be applicable to other future link technologies with high loss and long round trip times 🔥

the requirements are split into three groups. it's kinda arbitrary, tbh 💀 but here's how it goes: group one is about how a header compression scheme affects the rest of the Internet infrastructure. group two is about which kinds of headers MUST be compressed efficiently. group three is about efficiency and the stuff that comes from the link technologies we're expecting 🍓

2. Header compression requirements 💜

this part is giving cellular drama. several current standardization efforts in the cellular arena want to support voice over IP and other real-time services over IP, like GERAN (specified by the ETSI SMG2 standards group) and UTRAN (specified by the 3GPP standards organization) 🎀 it's critical for these efforts that a suitable header compression scheme is developed before completion of the Release 2000 standards. so it's imperative that the ROHC WG keeps its schedule ⏰

2.1 Impact on Internet infrastructure 🌸

1. Transparency: when a header is compressed and then decompressed, the resulting header MUST be semantically identical to the original header. if that can't be achieved, the packet containing the erroneous header MUST be discarded 🙈

Justification: the header compression process MUST NOT produce headers that might cause problems for any current or future part of the Internet infrastructure. no messing up the internet, periodt 💅

2. Ubiquity: it MUST NOT require modifications to existing IP (v4 or v6), UDP, or RTP implementations 🧚

Justification: ease of deployment. nobody wants to update everything 😭

Note: the ROHC WG may recommend changes that would increase the compression efficiency for the RTP streams emitted by implementations. however, ROHC cannot rely on those recommendations being followed 🥺

2.2 Supported headers and kinds of RTP streams ✨

1. IPv4 and IPv6: ROHC MUST support both IPv4 and IPv6 👑

Justification: IPv4 and IPv6 are both gonna be around for the foreseeable future, so we're not picking favourites 💖

2. Mobile IP: the kinds of headers used by Mobile IP{v4,v6} SHOULD be compressed efficiently. for IPv4 that includes headers of tunneled packets. for IPv6 that includes headers containing the Routing Header, the Binding Update Destination Option, and the Home Address option 🦋

Justification: it's very likely that Mobile IP will be used by cellular devices. the phones are gonna be on it 📱

3. Genericity: ROHC MUST support compression of headers of arbitrary RTP streams 🌈

Justification: there MUST be a generic scheme which can compress reasonably well for any payload type and traffic pattern. this doesn't stop optimizations for certain media types where the traffic pattern is known, like low-bandwidth voice and low-bandwidth video 🎀

Note: this applies to the RTP stream before as well as after it has passed through an internet ✨

4. IPSEC: ROHC SHOULD be able to compress headers containing IPSEC subheaders 🔐

Note: it's of course not possible to compress the encrypted part of an ESP header, nor the cryptographic data in an AH header. the encrypted stuff stays encrypted, bestie 🙅‍♀️

2.3 Efficiency 🔥

1. Performance/Spectral Efficiency: ROHC MUST provide low relative overhead under expected operating conditions. compression efficiency SHOULD be better than RFC 2508 under equivalent operating conditions. the error rate SHOULD only marginally increase the overhead under expected operating conditions 💅

Justification: spectrum efficiency is a primary goal, and RFC 2508 just doesn't perform well enough. it's not it 💀

Note: the relative overhead is the average header overhead relative to the payload. any auxiliary (e.g., control or feedback) channels used by the scheme SHOULD be taken into account when calculating the header overhead 🧮

2. Error propagation: error propagation due to header compression SHOULD be kept at an absolute minimum. error propagation is defined as the loss or damage of headers subsequent to headers lost or damaged by the link, even if those subsequent headers are not lost or damaged. it's like one bad header ruining the whole vibe 😭

Justification: error propagation reduces spectral efficiency and reduces quality. CRTP suffers severely from error propagation, and that's a big ick 🙈

Note: there are at least two kinds of error propagation. loss propagation is when an error causes subsequent headers to be lost. damage propagation is when an error causes subsequent headers to be damaged 🌸

3a. Handover loss events: there MUST be a way to run ROHC where loss events of length 150 milliseconds are handled efficiently, and where loss or damage propagation is not introduced by ROHC during such events 🦋

Justification: such loss events can be introduced by handover operations in a (radio) network between compressor and decompressor. handover operations can be frequent in cellular systems. failing to handle handover well can hurt spectrum efficiency and quality, and nobody wants that 📶

3b. Handover context recreation: there MUST be a way to run ROHC that deals well with events where the route of an RTP conversation changes, so that either the compressor or the decompressor of the conversation is relocated to another node and the context needs to be recreated. ROHC MUST NOT introduce erroneous headers during such events, and SHOULD NOT introduce packet loss during such events 🧚

Justification: these events can be frequent in cellular systems, where the compressor/decompressor on the network side is close to the radio base stations 📡

Note: to help developers of context recreation schemes where context is transferred to the new node, the specification SHALL outline which parts of the context are to be transferred, as well as the conditions for using them. procedures for context recreation (and discard) without such context transfer will also be provided 🫶

6. References 📚

Okay so, here's the reading list, bestie 🧚 Every reference is copied exactly as the RFC lists it, so nothing gets lost in translation:

[TR]      3GPP TR 23.922 version 1.0.0, 3rd Generation partnership
          Project; Technical Specification Group Services and Systems
          Aspects; Architecture for an All IP network.

[TS]      TS 22.101 version 3.6.0: Service Principles

[RFC768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
          August 1980.

[RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
          1981.

[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
          Serial Links", RFC 1144, February 1990.

[CRTP]    Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers
          for Low-Speed Serial Links", RFC 2508, February 1999.

[OHC]     Bormann, C., Editor, "Robust Header Compression (ROHC)", RFC
          3095, June 2001.

The [RFC768] and [RFC791] entries are the classic UDP and IP specs, and [RFC1144] and [CRTP] are the older header compression work that this whole story builds on 🦋

---

7. Full Copyright Statement 💅

Okay, legal stuff, but it's giving important 🎀 The Internet Society owns the copyright here (2001), and all rights are reserved.

Here's the vibe: you're allowed to copy this document and share it with other people. You can also write derivative works that comment on it, explain it, or help people implement it, and publish and distribute those however you like, in whole or in part, with no restrictions. The one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work 🔥

What you can't do is change the document itself. No removing the copyright notice, no removing references to the Internet Society or other Internet organizations. The only exceptions are when it's needed to develop Internet standards (in which case the Internet Standards process copyright procedures have to be followed), or when you're translating it into a language other than English 🌈

These permissions are perpetual. The Internet Society and its successors or assigns can't take them back ✨

Last but not least, the whole document and everything in it is provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Basically, no promises of any kind 💀

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. So the people who keep these RFCs organized and published are supported by them, and that's iconic ✨