Subject: [rohc] RoHCv2 issue #2: Two-step transition

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Wed, 20 Jun 2007 17:09:37 +0200

RoHCers,

Trying to bring this discussion to some conclusion.

It seems that in this case the issue is to motivate the two-step transition.

Well, the idea was originally to remove any possible error cases in case an IR updates at least one control field to a different value, when reordering is possible. Error cases are possible because control fields are not used to "decompress" the IR header.

Because we do not want to make mandatory to always send the control fields in the IR, and because there is no room for a 3-bit CRC in the IR to cover those fields, then the approach where the usage of the updated control fields is CRC-7 verified prior to allowing decompression of CRC-3 headers was proposed.

However, it's been argued on the mailing list that it might be too strict to mandate the decompressor to successfully verify a header with a CRC-7, before being allowed to attempt decompression of a header with a CRC-3. 

(Note that the co_common and co_repair headers do not either mandate that control fields are sent, however they contain a CRC3 over the context values for the control fields, hence these headers can both update these fields and verify them, although they may not use their value by CRC-7 verification. Therefore this issue applies only to the IR header.)

So, here is my proposal:

1) We could change the state machine to a "one-step" state machine, whereas
   when the compressor uses IR but do not modify any of the control fields
   it may send a header with a CRC-3 directly after, and

2) We could add in a normative section text similar to the following:

  "The compressor should not use a CO format with a CRC-3 immediately after having
  sent an IR header that updates at least one control field to a different value;
  the compressor SHOULD use a CO format with a CRC-7, and subject it to the
  optimistic approach it implements."

The consequence of 1) is that the decompressor may attempt decompression of a CRC-3 header whenever it likes, while the consequence of 2) is that a compressor will send a CRC-7 after updating the control fields with the IR header to ensure that the control fields are properly updated (unless it knows better, i.e. If it does not do that, the decompressor will still attempt decompression of the CRC-3 header)

Yet, in means in practice that we still strongly recommend (SHOULD) that a CRC-7 follows an IR header, but compression won't break if it is not the case and if reordering isn't an issue. IMO, increased robustness against reordering for control fields at such a low cost is quite good actually. I think that this porposal should be acceptable to everyone? It's flexible, can be made robust and it is not broken. Agreed?

Cheers,

///Ghyslain

 --
 Ghyslain Pelletier, Dipl. Ing.
 Senior Research Engineer
 Wireless IP Optimizations
 Ericsson Research, Corporate Unit

 Ericsson AB, Laboratoriegränd 11
 Box 920, S-97128 Luleå, SWEDEN
 Phone : +46 (0)  8 404 29 43
 Mobile: +46 (0) 70 264 83 14
 Ghyslain.Pelletier at ericsson.com
 http://www.ericsson.com

--------------------------------------------
 The opinions expressed in this message are
 my personal opinions.
 These opinions are not necessarily those of
 my employer, unless stated otherwise.
--------------------------------------------

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