Subject: [rohc] Impl. guide text: Context reuse revisited [again]

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Fri, 24 Sep 2004 12:49:36 +0200

Following up on the previous analysis and summary, here is a text
proposal for the implementer's guide.

Rgds,
/L-E

7. Context management and CID/context re-use

7.1. Compressor and decompressor MUST keep MAX_CID contexts

As part of the negotiated channel parameters, compressor and
decompressor have through the MAX_CID parameter agreed on the 
highest context identification (CID) number to be used. By
agreeing on MAX_CID, both compressor and decompressor also
agrees to provide memory resources to host at lest MAX_CID+1
contexts, and an established context with CID within this
negotiated space MUST be kept by both compressor and
decompressor until either the CID gets re-used, or the channel
is taken down or re-negotiated.

7.2. CID/context re-use

As part of the channel negotiation, the maximal number of
active contexts supported is negotiated between the compressor
and the decompressor through the MAX_CID parameter. The value
of MAX_CID can of course vary enormously between different
link scenarios, as well as the load in terms of actual packet
streams to compress. Depending on link technology, the ROHC
channel lifetime will also vary from almost permanent to
rather short-lived. However, in general it is not expected
that resources will be allocated for more contexts than what
can reasonably be expected to be active concurrently over the
link. As a consequence hereof, context identifiers (CIDs) and
context memory are resources that will have to be re-used by
the compressor as part of what can be considered normal
operation.

How context resources are re-used is in RFC 3095 [1] and
subsequent ROHC standards basically left unspecified and up
to implementation. However, re-using a CID and its allocated
memory is not always as simple as initiating a contexts with
a previously unused CID. Because some profiles can be
operating in various modes where packet formats vary
depending on current mode, care has to be taken to ensure
that the old context data will be completely and safely
overwritten, eliminating the risk of undesired side effects
from interactions between old and new context data.  

On a high level, CID/context re-use can be of two kinds,
either re-use for a new context based on the same profile as
the old context, or for a new context based on a different
profile. These cases, are discussed separately in the
following two subsections.

7.2.1. Re-using a CID/context with the same profile

For multi-mode profiles, such as those defined in RFC 3095
[1], when a CID/context is re-used for a new context based
on the same profile as the old context, the current mode of
operation MUST be inherited from the old to the new context.
The reason for this is that there is no reliable way for the
compressor to inform the decompressor that a CID/context
re-use is happening. The decompressor can thus not be
expected to flush the context memory for the CID, and there
is no way to trigger a safe mode switching, which requires a
decompressor-initiated handshake procedure, as defined in
section 5.6 of [1].

It should be noted that the rule of mode inheritance applies
also when the CONTEXT_REINITIALIZATION signal is used to
reinitiate an entire context.

7.2.2. Re-using a CID/context with a different profile

When a CID is re-used for a new context based on a different
profile than the old context, operation with that context
MUST start in the initial mode of the profile (if it is a
multi-mode profile). This applies both to IR-initiated new
contexts and profile downgrades with IR-DYN (e.g. the
IP/UDP/RTP->IP/UDP downgrade in [1] section 5.11.1).

A CID for an R-mode operating context SHOULD NOT be re-used
for a new context based on a different profile than the old
context, because of the R-0/R-1 misinterpretation risk (these
packets have no CRC). If a compressor still wants or has to
do this, the compressor must be very careful to minimize the
misinterpretation risk, e.g. by not using packets of types
beginning with 00 or 10 before the compressor is highly
confident that the new context has successfully been
initiated at the decompressor.

7.3. Context updating properties for IR packets

It should be noted that an IR does not flush the whole context,
but updates all fields carried in the IR header. Similarly, an
IR without a dynamic chain simply updates the static part of
the context, while the rest of the context is left unchanged.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Lars-Erik Jonsson (LU/EAB)
> Sent: den 22 september 2004 16:42
> To: [email-masked]'
> Subject: RE: [rohc] Context reuse revisited [again]
> 
> 
> ROHCers,
> 
> This thread has been silent since June, when we ended without any
> conclusions. Me an Kristofer met today to figure out what this
> issue is really about and what we can do to find a working solution
> to document in the implementer's guide. I think we managed to make
> some observations on the problem that have not really been clear
> from previous discussions, and based on these we have a proposal
> to get context handling principles that works. First our findings:
> 
> * We are actually not really discussing Context Reuse, but CID reuse.
>   Zhigang pointed this out in previous discussions and we should be
>   clear about the difference. However, the problem is that as it is
>   not easy to distinguish between an IR that initiates a new context
>   with a previously used CID, and an IR that just provides a complete
>   update for the existing context. CID reuse might thus imply some
>   context reuse, but still we should not see them as the same thing.
> 
> * When discussing CID reuse, we should be aware that contexts must
>   never be deleted as long as the channel is up. If N CID's have been
>   negotiated for the channel, both compressor and decompressor MUST
>   allocate memory for N contexts and keep the initiated contexts for
>   all these N CID's. There can thus never happen that a context has
>   been deleted at the decompressor side, while still being valid at
>   the compressor.
> 
> * The original question has turned into one complicated side-problem,
>   which is what mode is used after reusing a CID.
> 
> * We've previously agreed that when re-using a CID for a new context
>   based on a different profile, for a multi-mode profile the mode
>   must always be set to initial mode. Further, it is obvious that the
>   question of mode-inheritance does not apply for single-mode 
>   profiles, so this problem does not exist there. The problem is thus
>   limited to CID reuse for new contexts with the same profile as for
>   the previous context on that CID, if the profile is an RFC3095
>   profile or a profile based on any of these.
> 
> * We've said that we do not want to always set mode to initial mode
>   for any IR sent because that would take away the possibility of
>   using IR for context update. However, we have not previously noted
>   clearly that defining IR to mean "mode reset" does not even work,
>   as a handshake procedure is needed to change mode in a safe way. As
>   Vick pointed out in his mail, there is a reason for having these
>   "complicated" procedures when switching between modes with different
>   packet type interpretations. Having an IR to imply "initial mode"
>   would in case of IR losses mean that UO-0 packets could mistakenly
>   be interpreted as an R-0 by the decompressor, which would mean that
>   incorrectly decompressed packets would be forwarded in the network.
> 
> * All this boils down to the R-0 packet without a CRC, as the
>   decompressor will process any packet that it interprets as an R-0
>   without any error detection. Everything works fine as long as you
>   are operating in R-mode, but as we have seen we will get problems
>   when we try to reuse a CID that already has an existing context
>   currently running in R-mode.
> 
> * To avoid the risk of invalid R-0 interpretation, mode MUST be
>   inherited when a CID is reused for a new context based on the same
>   profile (for multi-mode profiles). 
> 
> * The same risk will still exist with CID reuse of an R-mode operating
>   context for a new context running a different profile, but that is
>   still less risky. However, the risk should be noted, and we must
>   recommended that a CID for an existing R-mode context SHOULD NOT be
>   reused for a new context with a different profile. When doing such
>   a reuse, the compressor must be very careful and aware of the risk.
> 
> 
> Proposed clarifications, to be captured in the implementer's guide:
> (of course not in this short form)
> 
> 
> 1) Context handling and CID's negotiated
> 
>    Both compressor and decompressor MUST keep all contexts
>    corresponding to the agreed set of supported N CID's (MAX_CID).
> 
> 
> 2) Reusing a CID for a new context based on a different profile
> 
>    When a CID is reused for a context of a new profile, operation
>    with that new context MUST start in initial mode of that profile
>    (if it is a multi-mode profile). This applies both to IR-initiated
>    new contexts and profile downgrades with IR-DYN (such as the
>    IP/UDP/RTP->IP/UDP downgrade).
> 
> 
> 3) Reusing a CID for a new context based on the same profile
> 
>    When a CID is reused for a context of the same profile, the mode
>    MUST be inherited if for an RFC3095 profile (or for a profile based
>    on a 3095 profile).
> 
> 
> 4) Reuse of a CID for an R-mode operating context
> 
>    Contexts running in R-mode SHOULD NOT be reused for a context of 
>    a different profile, as that would imply a R-0 misinterpretation
>    risk. If this is still done, the compressor must be very careful
>    to eliminate this risk.
> 
> 
> 5) Reinitialization with the CONTEXT_REINITIALIZATION signal
> 
>    Rule 3 applies also when the CONTEXT_REINITIALIZATION signal is
>    used to reinitiate the entire context.
> 
> 
> A) Additional note on IR without a dynamic chain
> 
>    An IR without a dynamic chain simply updates the static part of
>    the context, while the rest is not changed (as opposed to being
>    totally cleared out). 
> 
>    
> We hope to get your feedback on this!!
> /L-E

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc