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

["Jin, Haipeng" <[e-mail]>]

Hi, Ghyslain,

Thanks very much for your extensive summary on the related topics.
Please see more comments in line with [haipeng4].

Best Regards,
Haipeng
-----Original Message-----
From: Ghyslain Pelletier (LU/EAB)
[mailto:[e-mail]] 
Sent: Wednesday, October 11, 2006 6:05 AM
To: Jin, Haipeng; Kristofer Sandlund (LU/EAB); [e-mail]
Subject: RE: [rohc] RE: Questions on ROHCv2 profile draft

Haipeng,

Thanks for your comments, much appreciated.
I think that this is an interesting discussion. 

Summarizing the discussion so far, it seems that there are agreements on
the following:
- IR-DYN is generally problematic when it only has a CRC8.
- HD state transitions need to be more robust than in RFC3095
- ctrl fields (and the entire context) should be verified
  before allowing HD to FC state

Some further observations:
- although the pt_0_crc7 can be used for the transition
  from IC to FC, its existence does not have much to do
  with this state transition in fact (see other mail on RoHCv2
  robustness also sent today)

[Haipeng4] but the state transition logic is one of the main reasons
that you listed as why pt_0_crc7 is added. 
 
- IR-DYN is not suitable for a repair (not clear from RFC3095);
  co_common is more useful because it carries the same
  information AND has a CRC7 that verifies decompression

[Haipeng4] agree unless another crc7 is added as I suggested in previous
emails.
 
- IR-DYN's existence in RFC3095 is solely motivated by
  the "profile downgrade" "feature"

Some wishes heard in the discussion:
- allow transition NC->FC directly for IR
- allow transition IC->FC directly for IR-DYN

The two-step approach currently in RoHCv2 mainly aims to solve the issue
about IR-DYN not being suited (read - robust) for the transition IC->FC.
It also locks IR to the two-step approach, as IR also has some drawbacks
with respect to this transition, although much easier to fix (much on
this below).

[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. 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. 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. 

We've chosen the two-step approach among a number of alternatives. The
reason was to keep the "profile downgrade" functionality (but we're open
to debate that function).

Note that alternatives below may be independently applied to IR and/or
IR-DYN unless stated otherwise.

Problems addressed:
===================
o IR and IR-DYN headers carry optional fields.
o IR-DYN does not verify decompression or the entire context.
o ACK(IR-DYN) is unclear in what gets ACKed with respect to static
  fields and ctrl fields that were not part of the header.
o ACK(IR) is unclear in what gets ACKed wrt to ctrl fields
  that were not part of the header.

Considerations of the solution:
===============================
o must be more robust than in 3095 (reordering)
o should allow efficient transition to FC state

Possible alternatives:
======================
1) two-step approach
2) remove IR-DYN (not possible for IR, of course)
3) CRC3 over ctrl fields context values
4a) CRC7 and update all optional fields always (IR-DYN only)
4b) update all optional fields always (IR only)

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. 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).

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. Note that this discussion may also affect the last
call currently going for the ROHCv2 framework.

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. The extra crc3 does not add any value here.
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.  

Pros: Solves robustness issues for IR (transition NC->FC ok)
     
Cons: Does not solve all robustness issues with IR-DYN
      One more CRC in IR/IR-DYN format
      Compressor logic for received feedback even less clear

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? 

Pros: Solves robustness issues for IR (transition NC->FC ok)
      Solves robustness issues for IR-DYN (IC->FC ok)

Cons: One more CRC in IR-DYN format
      More overhead when default values are not matching the
      characteristics of the flow.
      May impact e.g. unidirectional operation.

Conclusion
==========
Possible solutions ...


o Solution 1:
-------------
Current 2-step approach (alternative 1 above).

Possibly combine with alternative 3 above with a CRC3 or with
alternative 4b above for the IR, to allow transition NC->FC for IR. But
no changes to IR-DYN, keep it locked to the 2-step approach. We believe
that the advantage of additional robustness of the two-step approach is
worth it, and certainly for IR-DYN.

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).   
[Haipeng4] If transition from NC or IC(RC) to FC based on IR is not
desired, we can also consider another solution which 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.

Change "IC" state to "Repair Context (RC)" state.
Use the following state machine:

                            CRC-8 Validation
                   +-->---->---->---->---->---->---->--+  CRC-8(IR)
                   |                     CRC-8(IR)     |  Validation
                   |                     Validation    |  CRC-7(CO) or
    CRC-8(IR)      |                     CRC-7(CO)     |  CRC-3(CO)
    Failure        |                     Verification  |  Verification
    +--->---+      |                     +-->---->--+  |  +-->---->--+
    |       |      |                     |          |  |  |          |
    |       v      |                     |          v  v  |          v
   +-----------------+  +----------------------+  +-------------------+
   | No Context (NC) |  | Repair Context (RC)  |  | Full Context (FC) |
   +-----------------+  +----------------------+  +-------------------+
       ^                 | ^ CRC-7(CO)      | ^                 |
       | Static Context  | | Failure or     | | Context Damage  |
       | Damage Detected | | PT not allowed | | Detected        |
       +--<-----<-----<--+ +----<------<----+ +--<-----<-----<--+
   where:
      CRC-8(IR) validation: successful CRC-8 validation for the IR
      header.
      CRC-7(CO) and/or CRC-3(CO) verification: successful CRC
      verification for the CO header, based on the number of CRC bits
      carried in the CO header.
      CRC-7(CO) failure: failure to CRC verify the decompression of a CO
      header carrying a 7-bit CRC.
      PT not allowed: the decompressor has received a packet type (PT)
      for which the decopressor's current context does not provide
      enough valid state information for that packet to be decompressed.
      Static Context Damaged Detected: see definition in Section 5.3.2.
      Context Damage Detected: see definition in Section 5.3.2.

o Solution 3:
-------------
Alternative 4 above, for IR and IR-DYN.
We're somewhat concerned by the cons of this alternative.
[Haipeng4] This is similar to solution 2. Could you please explain more
about the extra overhead problem? Regardless of whether the CRC7 is
added or not, if the characteristics do not match, then the HC can send
T1 or T2 packets. If T1/T2 is not enough, then co_common can be used
which will contain CRC7 anyway. If co_common is not enough, then IR or
IR-DYN needs to be sent anyway, what difference does an extra byte make
if the header is already more than 20 bytes?

Comments?

Best regards,

///Ghyslain

> -----Original Message-----
> From: Jin, Haipeng [mailto:[e-mail]] 
> Sent: den 10 oktober 2006 19:16
> To: Kristofer Sandlund (LU/EAB); [e-mail]
> Cc: Ghyslain Pelletier (LU/EAB)
> Subject: RE: [rohc] RE: Questions on ROHCv2 profile draft
> 
> Hi, Kristofer,
> 
> Please see comments inline with [haipeng3].
> 
> -----Original Message-----
> From: Kristofer Sandlund (LU/EAB)
> [mailto:[e-mail]]
> Sent: Monday, October 09, 2006 11:35 PM
> To: Jin, Haipeng; [e-mail]
> Cc: Ghyslain Pelletier (LU/EAB)
> Subject: RE: [rohc] RE: Questions on ROHCv2 profile draft
> 
> Hi Haipeng,
> 
> comments inline.
> 
> >>> 
> >>> 3) Is there a reason to have the packet type, pt_0_crc7, in RTP 
> >>> profile particularly since there is no R-mode in v2 profiles?
> >>> 
> >> 
> >> This packet is not meant for R-mode like behavior. If you 
> look at the 
> >> state machine in 5.3.1, you see that we have changed so 
> that we have 
> >> the new IC state, and we do not leave this until we have 
> received a 
> >> 7-bit CRC packet. In v1, you went directly from NC state up to FC 
> >> state on successful decompression, while now, we only move to IC 
> >> state. We feel that this logic will protect the context from 
> >> decompression errors a lot better, but we still want to 
> allow for an 
> >> efficient transition from IC to FC state, and that's why we want a 
> >> very small CRC-7 packet, which is the pt_0_crc7.
> >> 
> >> 
> >> [Haipeng] This is the part I don't fully understand. Do 
> you have any 
> >> specific scenarios in mind that this transition logic (in 
> combination 
> >> with pt_0_crc7) will help to improve? it seems to me co_common is 
> >> more likely to be used in this transition. For example, at initial 
> >> context setup, a number of IRs might be followed by one or more 
> >> co_common to establish the flags and control fields; in 
> decompression 
> >> error case, co_common is also likely to be the one for updating 
> >> contexts.
> > 
> > Which packet type is used after IR is pretty dependent on 
> both traffic 
> > and on how you implement your compressor, so I wouldn't say 
> that you 
> > will always go for co_common in this transition. There's nothing 
> > stopping you from guessing the control fields already at 
> the first IR 
> > packet, and ion many situations you can be pretty accurate on these 
> > guesses. In such a case, you wouldn't need to send a 
> co_common after 
> > the IRs, you could immediately start sending pt_0 packets.
> > 
> > Also, we want to avoid the case where you NACK and reply with an 
> > IR-DYN and immediately move back to FC state, since the 
> IR-DYN uses an 
> > 8-bit CRC which does not verify the context, only the actual packet 
> > itself.
> > This is a bit risky in case you have corruption on something not 
> > covered by the 8-bit CRC (e.g. the static fields or control fields 
> > that might not be present in the IR-DYN).
> > So, if you recover with an IR-DYN, you should send pt0_crc7 
> after this 
> > to make sure that your repair was successful before you 
> start sending
> > CRC-3 packets again. With 3095-logic, there are some nasty corner 
> > cases that can cause huge problems, so we really want to close the 
> > door on those with v2.
> > 
> > [haipeng2] In that case why not simply add a CRC7 to IR-DYN 
> to verify 
> > the context? I understand now the problem you are trying to solve 
> > here:
> > basically ensure robust transfer from IC to FC while at the 
> same time 
> > keep the overhead small by only sending a small 2B 
> compressed header. 
> > If overhead is not a problem (considering this type of 
> transition only 
> > happen rarely), one alternative to ensure robust is to send 
> co_common 
> > after IR or IR-DYN as I suggested in the previous message. 
> If overhead 
> > is really an issue here, then another alternative is to add 
> an extra 
> > byte to IR-DYN to include CRC-7 so that context update and 
> > verification can be done with one packet. Either way, we 
> can avoid the 
> > need to add a packet type just for this transition.
> 
> When we made the initial draft, we also discussed the 
> alternative of adding an additional CRC7 to the IR-DYN (we 
> must of course keep the
> CRC-8 that's already there since it is part of the 
> framework), but we preferred to instead add this packet 
> format so that we can enforce a "two-step transition". I also 
> prefer to force sending of CRC-7 packets even after an IR to 
> really verify that things are ok before moving on to CRC-3 
> packets, but maybe that's just my paranoia, though :) 
> 
> Both of these are valid solutions to the problem, but could 
> you please try to motivate what's you issue with the 
> pt_0_crc7 packet and why you think the other solution is preferrable?
> 
> 
> [Haipeng3] It seems an over kill to have one packet type just 
> for that transition :-) Anyway here come the more specific reasons:
> 1. In the IR-DYN + pt_0_crc7 two-step procedures, you are 
> assuming that IR-DYN may not update the entire context 
> correctly and thus it is necessary to use pt_0_crc7 to verify 
> it later. However, this implies that an error packet 
> decompressed based on the IR-DYN will be passed to the upper 
> layer. Having CRC7 inside the IR-DYN will avoid this problem 
> while achieving the same verification purpose. On the other 
> hand, if you don't see this scenario possible, then there is 
> no need to have
> pt_0_crc7 either.
> 2. In designing co_common in V2, the principle seems to have 
> one crc to verify the decompression/context and one crc to 
> verify the control fields that are not verified by the first 
> crc. I see no reason to apply a different principle to IR-DYN 
> packets. Why not just follow the same principle throughout 
> the V2 design?
> 
> Regards,
> Haipeng
> 
> > 
> >> 
> >>> 4) Why use the term "Initial Context (IC)" instead of "Static 
> >>> Context (SC)" as in RFC3095, the name SC seems more informative?
> >> 
> >> See explanation above. Mostly because you're not allowed to go 
> >> directly from NC to FC any longer. IC state can mean that 
> the context 
> >> is believed to be valid (but you don 't have that strong 
> confidence), 
> >> while SC did not mean this.
> >> 
> >> [Haipeng] Well, this may be true when the context is first 
> >> established. But when decompression error happens in FC state, the 
> >> decompressor transits back to this lower state with the assumption 
> >> that something is wrong in the context (as also indicated in the 
> >> current state diagram) and the error is more likely to be in the 
> >> dynamic part than the static part of the context. SC still 
> seems to 
> >> be more appropriate than IC.
> > 
> > See the IR-DYN repair case above for one example, we feel that a 
> > repair should always be verified with a CRC-7, and not only with 
> > CRC-8.
> > 
> > [haipeng2] I understand the robust transition problem, but 
> my point is 
> > what does the "IC" state mean to the decompressor? My 
> interpretation 
> > under both the cases you and I talked about is that "IC" here means 
> > the decompressor is more confident in its static context 
> than dynamic 
> > context even though both may be correct (or wrong). In this sense, 
> > "SC"
> > seems like a more appropriate name and it aligns with the 
> > understanding people had while reading RFC3095.  But it is just a 
> > symbol/name anyway, so if you like "IC" better, I wouldn't 
> argue too 
> > much about it.
> 
> I think the renaming of the state is important just to make 
> it clear to people that this is NOT the same transition logic 
> as in 3095. If we change the transistion logic but keep the 
> same name, I feel that it is much more likely that people 
> will confuse things and not notice the difference. So, I 
> don't really care if it should be called "IC"
> or something else completely, but I think it is important 
> that the name is not the same as before now that the logic is changed.
> 
> BR,
>    Kristofer
> 

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