Summary
- RFC 3409 recommended that a lower layer pass a packet with an erroneous compressed header to the ROHC decompressor with an explicit error indication, even though the packet itself had to be discarded.
- Unequal error detection could keep header integrity separate from payload damage, letting a tolerant application judge the payload instead of forcing the network to treat every error as a broken header.
Header compression makes small errors unusually consequential. A damaged ordinary packet may lose itself. A damaged compressed header can also mislead the shared context used to reconstruct later packets. RFC 3409 therefore asked lower layers to make residual errors in ROHC headers close to zero. Yet it did not tell those layers to erase every failed object before the decompressor could observe it.
The recommendation was subtle: pass the invalid packet upward with an error indication because the decompressor might make use of it, even though it must be discarded. The same object acquired two qualifications. It was not eligible for application delivery, but its labelled failure could remain evidence for the machine responsible for compression state.
Without the label, forwarding corruption would be dangerous. The decompressor might treat damaged bits as a valid context update. Without the object, dropping everything below ROHC would hide an event that could inform recovery. RFC 3409 preserved both the conservative data decision and the state observer's information.
The lower layer was already an author of reconstructed meaning. The IPv4 total length, IPv6 payload length and UDP length could be inferred from one per-packet length supplied by the link. The decompressor did not merely expand bytes it received; it combined compressed fields with facts produced elsewhere in the stack.
Error scope then determined how many useful packets survived. With one checksum over header and payload, any bit error made it impossible to know which part was damaged. ROHC had to assume the header might be wrong, because correct decompression could no longer be assured. A payload that a speech codec might have tolerated was discarded along with a possibly sound header.
Unequal error detection changed the decision graph. If the system could say that the compressed header was intact while only the payload was damaged, it could reconstruct the header and let the application judge whether the media remained usable. This was not a promise of good audio. It was a transfer of authority from an indiscriminate network discard to an application with subject-specific tolerance.
Unequal error protection was a separate option. Stronger protection for the header might reduce its error probability, but RFC 3409 noted that the benefit depended on unequal detection. If the receiver could not distinguish header damage from payload damage, extra protection did not create a trustworthy classification. Protection strength and diagnostic resolution were different controls.
The rest of the guidelines reinforced that evidence depended on location. Duplication before the compressor could be handled, though it wasted resources; duplication between compressor and decompressor was forbidden. Reordering before compression was acceptable, while the original ROHC path assumed no reordering between the paired state machines. The same event changed meaning according to where it occurred.
Handover added another boundary. A system could transfer compression context, or notify the compressor and reinitialize with full headers. A long loss burst without either evidence could make the context stale. Again, moving or refreshing state was distinct from proving that payload had been delivered.
Later ROHC documents changed parts of the surrounding framework and addressed reordering more directly. They do not supply a deployment result for this Informational RFC. Its lasting contribution is a vocabulary for partial validity: discard the data when required, preserve the labelled evidence when useful, and let the proper layer decide each consequence.
Sources
- https://www.rfc-editor.org/rfc/rfc3409.html
- https://www.rfc-editor.org/rfc/rfc3409.txt
- https://www.rfc-editor.org/info/rfc3409/
- https://datatracker.ietf.org/doc/rfc3409/
- https://datatracker.ietf.org/doc/rfc3409/history/
- https://datatracker.ietf.org/doc/rfc3409/references/
- https://www.rfc-editor.org/errata_search.php?rfc=3409
- https://www.rfc-editor.org/rfc/rfc3095.html
- https://www.rfc-editor.org/rfc/rfc3096.html
- https://www.rfc-editor.org/rfc/rfc1144.html
- https://www.rfc-editor.org/rfc/rfc2507.html
- https://www.rfc-editor.org/rfc/rfc2508.html
- https://www.rfc-editor.org/rfc/rfc2509.html
- https://www.rfc-editor.org/rfc/rfc1661.html
- https://www.rfc-editor.org/rfc/rfc3242.html
- https://www.rfc-editor.org/rfc/rfc3759.html
- https://www.rfc-editor.org/rfc/rfc4224.html
- https://www.rfc-editor.org/rfc/rfc4995.html
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
