RE: [rohc] RE: Questions on ROHCv2 profile draft

Haipeng,

Comments inline. I've clipped away what I think we don't need anymore.

///Ghyslain

Jin, Haipeng wrote:

> [Haipeng4] Could you please elaborate a little more about the
> IR drawbacks? The main point listed in your message below is
> that IR carries optional fields. I am still not convinced
> that is a problem.

Protocol-wise it is _possible_ for an HC implementation to make a repair
without including the optional fields, and it _can_ do this forever.

This is because the HC cannot know from the feedback message what went
wrong _exactly_, while it has the responsibility to identify what
information is needed for the repair.

We want to avoid defining a protocol that leaves open such possibility,
and adding a CRC7 does not solve this.

> The point I want to stress is that the robustness of ROHC
> really depends on both HC (header compressor) and HD
> (header decompressor), and maybe more on HC than HD.

Robustness depends solely on the compressor.
The selection of proper packet format is key. 

> It does not matter how many steps we have in the
> HD state transition logic, if the HC does not send enough
> context information or updates, the decompression will fail
> anyway. To improve robustness, it might make more sense to
> look at HC instead of HD.

I disagree. Sender requirements are implicit to receiver specifications.

Defining requirements based on the receiver is common practice. As
impairment events may occur during transmission from sender to receiver
and change the information flow (losses, reordering, residual bit
errors) it makes little sense to specify sender behavior when it can be
avoided. Furthermore, there is a broader range of possible
implementations for a sender than for a receiver, thus it is simpler and
more efficient to specify receiver requirements.

Clear receiver requirements in turns specify sender's behavior, without
constraining the implementation details and creating overspecified
protocols with redundant text.

More specifically in this case, the two-step approach aims at ensuring
that the HC will ensure that no packets having only a CRC3 will reach
the HD before HC has sent the necessary information for the HD to CRC-7
verify at least one decompression. This is done by specifying that the
HD must not attempt decompression of CRC3-protected header without
having first successfully decompressed a CRC7 protected header.

(...)

> Alternative 1: Two-step approach
> ============================================================
> As in current draft.
> 
> Pros: very robust against any error case (packet losses,
>       reordering AND residual bit errors),
>       removes corner-cases due to IR-DYN.
> Cons: 1 octet more than 3095 to move from IC->FC with pt_0_crc7?
> 
> [Haipeng4] It is actually one packet later than 3095 and one
> new packet type more than 3095.

I disagree. The exact same sequence is possible, only the size of
pt_0_crc7 and UO-0 (1 octet) over the OA approach differ.

RoHCv2 has removed a huge number of packet types, considering extensions
in RFC3095 and R-mode packet types. So this is a rather weak argument
against having pt_0_crc7, especially considering the robustness gains
that 2 extra MSN bits and a 7-bit CRC brings with respect to increased
robustness requirements on ROHCv2.

> As I pointed out in the
> previous message, the same robustness can be achieved in one
> step by adding the extra byte to IR-DYN or simply use
> co_common (already have the crc7).

In what sense using IR-DYN with an additional CRC7 instead of pt_0_crc7
is more efficient? IR-DYN with a CRC7 is still not robust wrt optional
fields, so I would not claim the above and I don't see it as an
improvement or a better solution.

We also have to make the difference here between:
1) going from NC to FC using the two-step via IC:

   i.e. NC->IC->FC will e.g. use OA*IR + OA*pt_0_crc7
   I would not use IR-DYN here anyway (even with a CRC7).
   Would OA*IR not be enough, I'd use e.g. with OA=3:
   IR
   IR(opt_fields)
   IR(opt_fields)
   co_common(opt_fields)
   pt_0_crc7               
   pt_0_crc7
   pt_0_crc3 ...

2) repairs:
   i.e. from IC->FC, co_common should be used (4-5 octets + update).
   I would not use IR-DYN here ever (even with a CRC7).

> Note: the two-step approach can be applied to IR and/or
> IR-DYN independently of each other.
> 
> Alternative 2: Don't use IR-DYN in RoHCv2
> ============================================================
> IR-DYN exists only because of the profile downgrade feature.
> Profile reuse is not a key feature of RoHC: good flow
> classification and the use of IR header when profiles need to
> be changed may very well be sufficient.
> 
> Pros: IR-DYN and associated problems disappears
>       (IR-DYN would not be used in RoHCv2)
> Cons: Only if some thinks profile downgrade is useful in
>       practice and worth the (implementation) effort
> 
> [Haipeng4] I am fine with not using IR-DYN in RoHCv2 but
> would be interested to see whether anyone relies on this
> packet type for the downgrade function.

The RoHCv2 profile work does not have any explicit requirement
about supporting profile downgrade using IR-DYN. But even if
it does and I am mistaking, I think its sound to discuss its
relevance to RoHCv2 profiles.

> Note that this
> discussion may also affect the last call currently going for
> the ROHCv2 framework.

Not at all, this has nothing to do with the RoHC framework.

The use of the IR-DYN packet type is profile-specific.
Common for all profile is the discriminator of the IR-DYN
format being reserved. Profiles may refrain from defining the
profile-specific part of the IR-DYN, in which case the IR-DYN
header is not used. For example, profile 0x0000 explicitely
does not define the IR-DYN format. 

Supporting profile downgrade is also profile specific, it must
be explicitely supported by the profile that is the target to
use the static part of a context that was associated with
another profile, using the IR-DYN. E.g. profile 0x0001 defines
downgrade from 0x0002.

Note: The framework described in 3095 and in the FW draft are
essentially identical, simply more clearly separated and
defined in the FW draft. In other words, RFC3095 profiles can
be used over the channel defined in the new draft, just like
RoHCv2 profiles can be used over the RoHC channel defined in
rfc3095.

> Alternative 3: Add CRC3 over ctrl fields context values
> ============================================================
> A CRC3 covering the values of ctrl fields in the context can
> be added to the IR and/or the IR-DYN format. As a value may
> not be available from the first packet in the flow, default
> initial values would have to be specified. In addition, CRC
> failure logic need to be augmented, e.g.
> failure for this CRC triggers context damage but the packet
> may be decompressed ok (ctrl fields aren't used for
> decompressing IR/IR-DYN).
> 
> [Haipeng4] The motivation for this extra crc3 is vague to me.
> My understanding is we need two CRCs at most in each packet,
> one is to verify that the control fields sent but not used
> for the current decompression are correct (e.g. crc8 in
> IR-DYN or CRC3 in co_common); the other is used to verify
> that the decompression is correct (e.g. crc7 in co_common).

> The success of decompression also indirectly verifies that
> context is correct.

Wrong. The success of the CRC7 verifies that the part of the
context that was _used_ to decompress the header is correct.

Specifically, for co_common, the control fields get updated
but are not (and will not be) used for the decompression of
the co_common header itself, hence the ctrl fields are not
verified by the CRC7.

This is the same for UOR-2-EXT3 in 3095 with e.g. TS_STRIDE.

> The extra crc3 does not add any value here.

The extra CRC3 protects the fields that are either optional
and/or not used in the decompression of a header that updates
their value, whether their value is present in the header or
not, by covering their value in the context.

Specifically wrt optional fields:
o CRC8 protects when the field is present in the header
o CRC7 protects only the decompression (i.e. ctx value used)
o CRC3 over optional field is as described above.

Clearly, CRC3 has value and makes things more robust.

> Introducing it actually causes more problems, for example, it
> would need to be added in all context update and verify
> packets including IR, IR-DYN, co_common since none of these
> packets sends the entire context.
> 
> The presence of ctrl fields would still be optional in the
> IR/IR-DYN header format.
> 
> [Haipeng4] As stated above, the control fields are already
> indirectly verified by the decompression.

Not always. See above.

(...)

> Alternative 4: Add CRC7 (IR-DYN), update all optional fields
> ============================================================
> All optional fields get updated, present (from the value in
> the header) or not (from a default value) in the format.
> The CRC8 protects what is sent, and what's not sent gets a
> clear value. This ensures that ctrl fields don't get
> corrupted by e.g. residual bit errors.
> 
> For IR-DYN, a CRC7 would be necessary to also verify the
> decompression (e.g. to cover for the static fields)
> 
> [Haipeng4] similar to the comments above, it is not clear why
> we always need to update all optional fields. co_common has
> options to update only some of the control fields. If
> co_common works fine, then why wouldn't IR-DYN with the extra
> CRC7 work?

Well, the co_common works fine because it has the CRC3.

CRC8 and CRC7 do not protect a ctrl field that is not
present in the IR-DYN header. See also above on CRC3.

(...)

> o Solution 2:
> -------------
> 
> Remove IR-DYN (alternative 2 above).
> Use alternative 4b above for IR (or alternative 3 with a CRC3)
> 
> [Haipeng4] As stated above, the need for 2-step is really
> eliminated if
> CRC7 is added to co_common and IR-DYN (or simply remove IR-DYN).

CRC7 is already in the co_common format.

Solution 2 as proposed as an alternative to what's in the current draft
already eliminates the two-step approach.

For this, IR and IR-DYN must be fixed:
o IR: optional fields must be protected/validated
o IR-DYN: same as IR + the static part must be protected/verified
  because of possible ooo. Or remove it.

> [Haipeng4] If transition from NC or IC(RC) to FC based on IR
> is not desired, we can also consider another solution which

I'm lost here, I thought you were after allowing the IR to move
from NC->FC???

> is similar to solution 2 but with the following changes:
> 1. no NC -> FC transit, instead NC -> IC(RC) 2. transition
> from IC(RC) to FC is based on CRC7, which can be provided by
> either co_common or IR-DYN with CRC7.

(...)

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc