Summary

  • RFC 3321 let a compressor use an explicit acknowledgement as evidence that state had been established at a remote decompressor, especially over an unreliable transport.
  • That evidence aged: memory pressure, later state creation and retention rules could remove an acknowledged state, so the compressor had to track remote capacity and treat a later STATE_NOT_FOUND as a new fact.

A receipt for creation, not a lease

RFC 3321 entered the SigComp story in January 2003 with an attractive proposition. If two signaling endpoints could remember earlier messages, later messages could be compressed against that shared history. The compressor would no longer have to treat every SIP or RTSP message as an isolated object. But dynamic compression only works when the sender’s model of the receiver’s memory is correct. Referencing a dictionary that the remote Universal Decompressor Virtual Machine cannot retrieve does not merely reduce efficiency; it can make decompression fail.

The document therefore gave the compressor a receipt. An explicit acknowledgement identifies a state that the decompressor successfully saved. RFC 3321 calls such a reference an acked_state_id and says a compressor must use only states established at the remote decompressor. On an unreliable transport, where a state-creating message can be lost or reordered, that confirmation closes a real evidence gap.

It does not close every later gap. The acknowledgement reports an event: the state was established. It does not freeze the receiver’s memory, reserve the bytes forever or promise that no later state will displace them. This temporal limit is the article’s central boundary. The receipt can be accurate when issued and stale when acted upon.

Reliable delivery is not permanent retention

RFC 3321 notes that a reliable transport such as TCP guarantees reception of prior messages, whereas an unreliable transport needs SigComp’s explicit acknowledgement mechanism. That sentence is easy to overread. Reliable delivery answers whether the message arrived in order. It does not by itself answer whether an application authorized a state-save request, whether enough state memory existed, or whether the saved state survived subsequent memory management.

The baseline RFC 3320 article in this series addressed the first distinction: successful decompression is not authorization to create persistent state. RFC 3321 begins after that gate. Even an authorized, created and acknowledged state has a lifecycle. A compressor that collapses transport delivery, state creation and continuing availability into one “confirmed” bit removes the very distinctions needed to explain a later failure.

The checkpoint was important, not immortal

RFC 3321’s checkpoint mechanism makes the lifecycle visible. A compressor can mark a newly created state with the highest retention priority it has sent and require an explicit acknowledgement. Yet the same section lists three reasons a referenced state may not exist: the creating message was lost; insufficient memory prevented creation; or the state was created and later deleted because memory became insufficient.

The third case is decisive. It means a valid acknowledgement and a later missing state are not contradictory records. They describe different times. A checkpoint is a preferred recovery anchor under the deletion rules, not an exemption from finite memory.

The compressor is told to track how much state memory the remote endpoint makes available. The state_memory_size parameter can support an inference that a previous checkpoint was deleted when a later checkpoint creation consumed the available space. “Can support an inference” matters. The parameter is not a remotely queryable inventory that names every surviving state. The compressor still has to combine capacity, creation order, age and retention priority into a current belief.

An implicit acknowledgement could outlive its referent

Shared compression adds a more surprising version of the same problem. An endpoint can save an uncompressed message as shared state and indicate that the peer may use it. RFC 3321 describes an optimization in which later use of that shared state implicitly tells the first endpoint that a companion state was created remotely. This can avoid carrying a separate acked_state_id.

The optimization has a race with memory. RFC 3321 warns that announcement information may be forwarded successfully even though the state it appears to confirm is then discarded for lack of state memory. Without accounting for that possibility, the next compressed message can depend on a state that no longer exists. Again, the signal is not necessarily forged. Its scope is simply narrower than “the state is present now.”

This is why the protocol’s evidence has to remain typed. A returned identifier can represent acknowledged state, shared state or global state, and RFC 3321 leaves parts of the extended message format to implementations. A basic SigComp implementation can ignore identifiers for the extended mechanisms. Seeing bytes in a feedback field is therefore not enough; the compressor needs the mechanism, mapping and current lifecycle context that give those bytes meaning.

The correction made uncertainty explicit

RFC 4896 later clarified SigComp’s retention rules. The ordering is counterintuitive: retention priority 65535 is below 0, followed by 1 through 65534. More importantly, retention priority belongs to a compartment’s reference, and multiple pieces of minimum-priority shared state can make the receiver’s contents ambiguous to the compressor.

The correction provides examples in which both endpoints follow the SigComp rules and the compressor nevertheless continues to believe that shared state remains available after it has been pushed out. Its conclusion is operationally strict: a compressor should not reference a state unless it can be sure the state exists. An advertisement can promise availability for the lifetime defined by age and retention-priority deletion rules; it is not a promise of permanence.

RFC 4077 later supplied a negative acknowledgement for the moment the optimistic model fails. STATE_NOT_FOUND identifies a referenced state that could not be retrieved and ordinarily causes the compressor to stop using it for future messages. That NACK is new evidence, not proof that the earlier acknowledgement was false. Between the two records lies the history of retention, eviction and belief.

RFC 3321’s lasting lesson is therefore less about a particular compression ratio than about receipts with time boundaries. “Created remotely” is a useful fact. “Still retrievable” is a different fact. A protocol remains intelligible only when it preserves both.

Sources