[rohc] Robustness considerations in RoHCv2

["Ghyslain Pelletier \(LU/EAB\)" <[e-mail]>]

All,

Let's try to summarize some of the robustness features of RoHCv2, wrt to
the recent discussions about IC to FC state transition and to new
requirements posed by the possibility to have reordering between
compression endpoints.

Those interested in this discussion should not necessarily answer to
this mail (I want to use it as a reference, not as a discussion object)
and instead answer the next mail I will send in the discussion.

Some background first:
======================
Keep the following guidelines in mind:
1) reordering increases the requirements on robustness
2) under the _same_ operating assumptions as RFC3095,
  compression efficiency should be at least equivalent

>From this, we've:
o added a CRC3 over control fields
o used a new philosophy wrt compressor confidence of the
  decompressor state
O created a new small packet type (pt_0_crc7).

IC (Initial Context)
====================
RFC3095 uses IR/SC/FC decompressor states. This logic is based on what
_part_ of the context is assumed valid (i.e. NONE, STATIC or FULL). IR,
IR-DYN and UOR-2* allow a direct transition to FC state (while in fact
the logic should be based on if the context is initialized or not, needs
validation or not, or is valid or not and what type of packets can be
decompressed in each case)

So, in other words the philosophy in 3095 is based on the confidence wrt
what part of the context the decompressor has received, not on what part
of the context it has validated (based on decompression of specific
packet types) before it can decompress the smallest packet types.

o Proposed increased robustness in RoHCv2:
------------------------------------------
In RoHCv2, the philosophy wrt robustness and what packets may be
decompressed is based on a confidence about the _validity_ of the
_entire_ context (not parts of the context as in 3095), not only on the
assumption that some of the information was properly received as in
3095.

We wanted to make the transition towards FC as robust as possible, so
we've made it a two-step process were the requirement is that the
context be validated at least once with a CRC7 packet before
decompressing CRC3 packets. This is the safest approach we've found for
addressing 1) above.

In RoHCv2, the context is either:
o invalid/uninitialized (NC)
o in some initial state where it is believed to be valid
  as information was received correctly (CRC8) but hasn't
  been used for decompression yet (no CRC-7 verification) OR
  has previously been CRC-7 verified but now in need of a
  repair from a failure of at least one CRC of any type (IC)
o entirely valid and suitable to decompress any packet type
  (CRC-7 verified) (FC).

We feel that this removes many (if not all) of the ugly corner cases
that 3095 did not address.

Namely, the condition that allows the decompressor to attempt
decompression of the smallest packet types is that the entire context,
including control fields (_and_ their use for decompression), is first
verified. This corresponds to the transition from IC to FC state in the
draft.

o Problem addressed:
--------------------
IR-DYN headers carry optional fields and do not verify decompression and
the entire context. ACK(IR-DYN) is unclear in what gets ACKed.

We wanted to avoid this.

This can be solved by:
- making all fields mandatory in the IR-DYN (to avoid unsuccessful
  repairs due to an optional field not in the IR-DYN header while
  it needed an update itself), and by adding a CRC7 over the
  uncompressed header.
- making the transition from IC to FC more robust and requiring
  the decompression of a CRC7 header, together with a new small
  CRC7 header type (pt_0_crc7). 

We've chosen the second option.

o Problem addressed (from 3095):
--------------------------------
UOR-2-EXT3 updates control fields without CRC protection.
ACK(UOR-2-EXT3) validates the update of the control field(s), but these
aren't verified.

We wanted to avoid this too.

We've chosen to add a CRC3 over the control fields in the UOR-2-EXT3
replacement.

o Problem addressed (from 3095):
--------------------------------
IR-DYN can be used to repair a context, but it carries optional fields
and it does not verify the context.

We wanted to avoid the IR-DYN to be used to make+validate a context
repair at once (co_common is more suited).

We've chosen to restrict IR-DYN to the IC state looping there until a
CRC7 is received and successfully decompressed.

Purpose of CRC3 over control fields
===================================
Protect updating of control fields against residual bit errors.

A 3-bit CRC is used to validate all the control fields that are updated
in co_common. This only guarantees that the information was received
properly, not that it was used sucessfully when decompressing, as
normally a header that carry control fields may not use these fields
when decompressed. Failure to verify this CRC is interpreted by the
decompressor as a decompression failure. Used in combination with the
requirements for the transition from IC to FC state, this makes the
updating of control fields more robust. 

///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