Subject: [rohc] ROHCv2 profiles: Decompressor state transitions and IR

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Mon, 16 Oct 2006 16:15:05 +0200

Hi all,

since we seem to agree on the removal of IR-DYN, we should continue 
the discussion on decompressor state machine, which also requires us 
to think about if and how we want to change the IR format.

Two-step transition:
- IR is unchanged
- The state machine as in the draft now is unchanged

One-step transition:
1) IR is unchanged. This still contains some minor risks since we have 
optional control fields that are not used for decompression and 
therefore there's a chance that too-smart-for-their-own-good 
implementations can end up in situations where everything fails.

2) IR is updated in one of the following ways:
   a) Add a CRC-3 that always convers the UVALUE of ts_stride, 
   time_stride and possibly some other control fields (this CRC-3 is 
   always calculated no matter if the value of these fields are present
   or not in the IR). To completely strengthen up this logic, we 
   suggest also adding the following:
     - Add a new feedback option which can be used by the decompressor
     in NACKs to indicate that the control fields must be updated (if 
     CRC-8 fails and CRC-3 succeeds, the decompressor can identify this 
     problem). This pretty much guarantees that the decompressor can 
     request a repair that will fix its problems when operating 
     bidirectionally.
     - Improve the text for unidirectional operation to make sure that 
     the periodic updates "SHOULD always explicitly contain the values 
     of any control fields whose values have been changed since the 
     association of this CID with the current profile"

   b) Change encoding of optional control fields so that they always 
   update the value no matter if they are explicitly present or not 
   (zero_or_irregular encoding for most of these). Downside of this
   is that when this type of control fields are used, it adds quite a 
   bit of voerhead since all IRs will have to contain explicit values.
   What mitigates this is that IRs will very seldom be used, and 
   therefore it might be ok to tolerate this overhead.

   c) Change coverage of CRC-8 to include control fields' values in the
   context. There's one problem with this approach, and that is the 
   fact that the CRC-8 is computed before the values in the packet have
   been read, and if the ts_stride is present in the packet, the CRC-8
   would have to verify BOTH the new value as well as the old value, 
   which would not be the intended concequence. Therefore this option 
   does not work.

My opinion is that the current two-step logic is completely fine, but 
if we want a one-step transition, I think 2a) or possibly 2b) are the 
only acceptable solutions. Comments?

/Kristofer

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

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 18 Oct 2006 08:57:56 +0200

Kristofer & others,

> - The state machine as in the draft now is unchanged

I have not been convinced this whole issue of two- versus one-step
really is a big thing, so I think keeping two-step is an appealing
choice.

> implementations can end up in situations where everything fails.

As this alternative is not completely safe, and I think it should
be avoided.

>    a) Add a CRC-3 that always covers the UVALUE of ts_stride,
>    time_stride and possibly some other control fields (this CRC-3
>    is always calculated no matter if the value of these fields
>    are present or not in the IR). To completely strengthen up
>    this logic, we suggest also adding the following:
>      - Add a new feedback option which can be used by the
>        decompressor in NACKs to indicate that the control fields
>        must be updated (if CRC-8 fails and CRC-3 succeeds, the
>        decompressor can identify this problem). This pretty much
>        guarantees that the decompressor can request a repair that
>        will fix its problems when operating bidirectionally.
>      - Improve the text for unidirectional operation to make sure
>        that the periodic updates "SHOULD always explicitly
>        contain the values of any control fields whose values have
>        been changed since the association of this CID with the
>        current profile"

To me, this seems to be the best (tm) one-step solution, no actual
negative aspects!

/L-E