Subject: RE: [rohc] Context reuse revisited [again]

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 22 Sep 2004 16:42:20 +0200

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

> -----Original Message-----
> From: Lars-Erik Jonsson (LU/EAB) 
> Sent: den 10 juni 2004 10:52
> To: Vicknesan Ayadurai (KI/EAB); Haipeng Jin
> Cc: [email-masked]'; 'Kristofer Sandlund'
> Subject: RE: [rohc] Context reuse revisited
> 
> 
> Yes, Vick is right that one must be careful when modifying the
> mode transition process. As some packet types gets totally changed
> by changing mode, the three-way handshake is needed to ensure
> unambiguous interpretation of these packet types.
> 
> /L-E
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > Vicknesan Ayadurai (KI/EAB)
> > Sent: den 9 juni 2004 22:24
> > To: Haipeng Jin
> > Cc: [email-masked]'; 'Kristofer Sandlund'; Lars-Erik 
> Jonsson (LU/EAB)
> > Subject: RE: [rohc] Context reuse revisited
> > 
> > 
> > Hi Haipeng,
> > 
> > There's more to the mode transitions mechanism than meets the eye.
> > 
> > > the old context. When the compressor  receives ACK with 
> > mode indication,
> > > the mode transition process will be initiated at the 
> > compressor side. The
> > > decompressor doesn't need to set D_TRANS as it would in a 
> > normal mode
> > 
> > The line above from your reply, would simplify mode transitions
> > significantly. However, as it stands, there's probably (hopefully?)
> > good justification for the "complications"  built into all 
> (but U->O)
> > mode transitions to ensure synchronisation during the process over
> > potentially erroneous links, with relatively large RTTs, e.g., via
> > requiring the need for a 3-way handshake, setting of D_TRANS/C_TRANS
> > flags, the requirement to send "common" packet formats only 
> during the
> > process, etc.
> > 
> > Regards,
> > vick
> > 
> > On Wed, 9 Jun 2004, Haipeng Jin wrote:
> > 
> > > At 02:01 AM 6/9/2004, Lars-Erik Jonsson (LU/EAB) wrote:
> > > >And after some more thinking...
> > > >
> > > > > Some reflections...
> > > > >
> > > > > > As per earlier discussions (february/march 2004), we decided
> > > > > > on mode inheritance when a CID is re-used by the compressor.
> > > > > > We also came to the conclusion that even if the compressor
> > > > > > would start in initial mode (U-mode), the decompressor
> > > > > > would (knowingly or unknowingly) initiate a mode transfer
> > > > > > since it will ACK the IR packet anyway (see 5.4.2.2.
> > > > > > and 5.5.2.2).
> > > >
> > > >There is a problem with this. I do not think mode transition can
> > > >ever be be "unknowingly" initiated, as the decompressor would
> > > >in the above case not set D_TRANS = I, so even if the CRC is
> > > >included the decompressor would not really initiate a transition.
> > >
> > > This shouldn't be a problem. The main objective here is to let the
> > > compressor transit to the same mode that the decompressor 
> > inherited from
> > > the old context. When the compressor  receives ACK with 
> > mode indication,
> > > the mode transition process will be initiated at the 
> > compressor side. The
> > > decompressor doesn't need to set D_TRANS as it would in a 
> > normal mode
> > > transition, it simply assists the compressor mode 
> > transition by sending ACK
> > > with mode indication.
> > >
> > > For a 3095-conformant decompressor, these ACKs are 
> > triggered by the IR
> > > packets sent to initiate the new context and the subsequent 
> > IR/IR-DYN/T2
> > > packets generated by compressor mode transition. As a results, the
> > > compressor can transit from U mode to either O/R mode, while the
> > > decompressor always works in the inherited O/R mode.
> > >
> > > Thanks,
> > >
> > > Haipeng
> > >
> > > >What we might have to require is:
> > > >1) A compressor that sees feedback indicating a different mode
> > > >    than the compressor is actually working in should start
> > > >    sending mode information in packets (Extension 3).
> > > >2) A decompressor that gets mode information from the
> > > >    compressor that does not match the operating mode of the
> > > >    decompressor should immediately initiate a mode transition
> > > >    procedure to desired mode.
> > > >
> > > >Comments? I guess there are even more issues...  =(
> > > >
> > > >/L-E
> > > >
> > > >
> > > >
> > > >_______________________________________________
> > > >Rohc mailing list
> > > >[email-masked]
> > > >https://www1.ietf.org/mailman/listinfo/rohc
> > >
> > >
> > > _______________________________________________
> > > Rohc mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/rohc
> > >
> > 
> > _______________________________________________
> > Rohc mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/rohc
> > 
> 

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