[rohc] Purpose of pt_0_crc7

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

All,

Let me summarize the purpose of pt_0_crc7, as it is not in fact only
related to the current discussion about IC to FC state transition.

///Ghyslain

Purposes of pt_0_crc7
=====================
Purpose 1:
----------
Efficient transition from IC to FC with a small CRC7 protected header.

By introducing the above condition for the decompressor to enter the FC
state by the IC state, and thus to start decompressing headers with a
3-bit CRC with the entire context + control fields verified, there were
alternatives:

a) use co_common or pt2. This would somewhat against 2) above,
   as 3095 allows a 1 octet header to be decompressed already
   after an IR/IR-DYN
b) add a CRC7 to IR-DYNs, in addition to the already existing
   CRC8. Possibly a CRC3 would be needed as well. This would
   go against 2) somewhat, although it would be marginal.
c) create a new packet type similar to pt0 but with a CRC7.

We've chosen c) because the combination of the condition to leave IC
state with the very small pt_0_crc7 packet type in particular will
protect the context from decompression errors in the most robust manner
while still allowing that transition to be efficient. co_common is
always an alternative otherwise when pt0-crc7 is not possible (e.g. ctrl
fields need to be updated).

Purpose 2:
----------
Efficient and more robust 3095-pt-0 replacement for high-reordering/loss
rates.

In some situations such as if the amount reordering is known to be high
(e.g. from the reordering ratio used), it may be desirable to have a
packet that can be more robust, using a CRC7, while still be spectrally
efficient. Or simply to lower the probability that a crc3 succeeds where
it shouldn't. pt0 or pt1 cannot serve this purpose as they have CRC3.
pt2 and co_common are too large for this.

Purpose 3:
----------
Robustly shorten OA repetitions when ooo delivery and high reordering
depth possible.

The pt_0_crc7 can be used to make the OA repetitions shorter when the
reordering depth is quite large, and replace e.g. a fraction of the OA
repetitions while still providing reliable detection of faulty
decompression. 


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