RFC 3095: ROHC Started Without a Return Channel

Summary

RFC 3095 required every ROHC context to start in unidirectional mode, where periodic refresh and observed header behavior substituted for a return channel.
A decompressor could then request optimistic or reliable bidirectional operation. Those modes spent feedback differently, so an acknowledgment described the health of one compression context—not end-to-end delivery.

The first packet could not assume a reply

Robust Header Compression was built for a difficult accounting problem. An RTP voice packet might carry a small payload behind IP, UDP and RTP headers whose fields repeat or move predictably. Sending every repeated bit over a scarce radio link wastes capacity. Omitting those bits, however, means the receiver must reconstruct them from state shared with the sender. A lost update can then damage packets that the link delivers perfectly.

RFC 3095 did not answer that risk with one universal operating rule. It separated state from mode. Compressor states—Initialization and Refresh, First Order and Second Order—described how much of a header's behavior had become predictable. Decompressor states—No Context, Static Context and Full Context—described what could safely be reconstructed. Modes answered another question: what return-path authority was actually available to coordinate those states?

The answer began conservatively. The RFC says compression must start in Unidirectional mode. U-mode works when a path from decompressor back to compressor is unavailable or undesirable. Its compressor advances by an optimistic rule: after sending enough information, it may become fairly confident that the receiver can decode a smaller form. Periodic timeouts, refreshes and irregular changes force it back toward richer packets when confidence should be renewed.

“Fairly confident” is not the same as “acknowledged.” It is an engineering response to a missing capability. The compressor can repeat context often enough to bound the damage of silence, but it cannot convert silence into proof that the far end received the update.

The decompressor opened the bidirectional modes

RFC 3095 did not let the compressor declare a return path into existence. After a packet reached the decompressor, the decompressor could send feedback carrying a desired mode. Only then could the context move from U-mode toward one of the bidirectional modes.

That allocation of authority matters. The decompressor is the endpoint that can observe whether reconstruction succeeds. The compressor sees what it sent, not what the peer could rebuild. A mode request therefore travels from the actor bearing the immediate context failure back to the actor choosing the next compressed form.

The later clarification in RFC 4815 made the coordination boundary sharper. It described mode change as a three-way handshake intended to move compressor and decompressor coherently. Packets around the acknowledgment boundary had to be decoded under the correct old or new rule. A label such as “reliable” could not replace an explicit transition procedure.

Optimistic feedback was deliberately sparse

Bidirectional Optimistic mode added a feedback channel without turning every packet into a receipt. The decompressor could send recovery requests and optionally acknowledge significant context updates, but pure sequence-number updates did not receive the same treatment. Periodic refreshes disappeared. The design aimed to keep compression efficient and feedback sparse.

That choice moved risk rather than abolishing it. O-mode could recover from detected context trouble without paying the continuous refresh cost of U-mode. Yet RFC 3095 warned that context invalidation could be more frequent than in Reliable mode, especially through long bursts of loss or errors.

The important word is context. A negative acknowledgment says the decompressor's reconstruction state needs attention. It does not say whether a voice frame was intelligible, whether an application consumed the payload, or whether a user heard a sentence. ROHC's feedback loop was local to the compression channel.

Reliable mode secured references, not outcomes

Bidirectional Reliable mode spent more of the return channel. It used stricter logic and acknowledged all context updates, including sequence-number-field updates, although not every R-mode packet changed context. Its secure-reference principle allowed only packets carrying a seven- or eight-bit CRC to update decompression context and become references for later packets.

This was a precise form of reliability. If a compact packet depends on an earlier reference, the reference must have enough checking and acknowledgment discipline to deserve that role. RFC 3095 aimed to reduce loss and damage propagation when headers or feedback were lost or corrupted.

It did not promise impossibility of failure. The RFC discusses residual bit errors, CRC coverage and cases in which damaged headers may still reach upper layers. “Reliable” names the mode's context-synchronization strategy relative to U- and O-mode; it is not a certificate for the payload, the application or the end-to-end path.

The return channel belonged in the cost ledger

RFC 3096 explains why this design mattered. The ROHC work targeted links with high error rates and long round-trip times, naming cellular technologies such as WCDMA, EDGE and CDMA-2000. It required semantic transparency: decompression should reproduce the original header, or the erroneous packet should be discarded. It also defined error propagation as later headers becoming unusable because an earlier header was lost or damaged.

The requirements refused a convenient accounting trick. Any auxiliary control or feedback channel had to count toward relative overhead. A tiny forward header was not the whole cost if it depended on reverse traffic, acknowledgments or recovery messages.

RFC 3409 carried the same boundary into link integration. U-mode could operate without feedback. O- and R-mode required the lower layer to transport feedback, preferably promptly. The protocol could exploit a return path; it could not assume every link supplied one at the needed latency.

Later documents preserved the distinction between text and operation

The record continued to change. RFC 4815 collected corrections and clarifications. RFC 4995 later separated the framework from individual profiles, noting that implementers had found parts of RFC 3095 complex or obscure while describing the two framework definitions as compatible. RFC 5225 defined revised ROHCv2 profiles with simplifications and additional robustness tools for loss and reordering.

Those documents prove continued specification work. They do not identify a deployed operator, measure spectrum savings, prove a handover, or show that two particular products interoperated. RFC 3241 similarly proves that PPP obtained a standardized way to negotiate and carry ROHC, not that a named link used it.

The durable historical lesson is narrower and more useful. RFC 3095 made feedback a capability with a direction, a cost and an owner. It began where that capability was absent, let the observing endpoint request stronger coordination, and kept three kinds of evidence separate: what the compressor predicted, what the decompressor confirmed about shared context, and what only an end-to-end observation could establish.

ROHC Began Without a Return Channel: RFC 3095

Why it matters

Summary

The first packet could not assume a reply

The decompressor opened the bidirectional modes

Optimistic feedback was deliberately sparse

Reliable mode secured references, not outcomes

The return channel belonged in the cost ledger

Later documents preserved the distinction between text and operation

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing