[rohc] RE: Purpose of pt_0_crc7

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

Hi, Ghyslain and all,

Please see my comments in line.


-----Original Message-----
From: Ghyslain Pelletier (LU/EAB)
[mailto:[e-mail]] 
Sent: Wednesday, October 11, 2006 6:04 AM
To: Jin, Haipeng; Kristofer Sandlund (LU/EAB); [e-mail]
Subject: Purpose of pt_0_crc7

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

[Haipeng] I'm not sure that (c) is always the most robust option. In
fact, if in (c), an IR-DYN packet is sent and the IR-DYN is decompressed
incorrectly, it will mean that one erroneous packet is passed up to the
application, and only the next pt_0_crc7 packet will catch this. In
cases (a) and (b), on the other hand, since IR-DYN (assuming we add
crc7) and co_common have CRC7, no erroneous packet passes decompression.
With the extra crc7, a) is not exactly equivalent to 3095. It is
actually more robust.


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.

[Haipeng] If reordering is expected, systems will typically set the
reordering parameter so as to handle a high percentage of cases. From
our experience with 3GPP2 systems, if we set the appropriate reordering
value in RoHC, the chances of packets having higher reordering than the
expected range is 10^(-5) or even lesser (and erroneous decompression
for crc3 would be 1/8th of this). Given that air-links typically have
error rates of 10^(-2), the gain of detecting erroneous decompression
"faster" with crc7 in such very small percentage cases is insignificant.
For 3gpp system, the same applies.

[Haipeng] Also, pt_0_crc7 packet only helps in detecting "bad"
decompression faster, and the detection process maybe 1 or 2 packets
faster than a CRC3. The probability difference is about 1/10 on top of
the already very small residual error probability. Having this
functionality for such an insignificant fraction of packets is overkill,
in my opinion. On the other hand, if a system is having a very high
amount of reordering (greater than what Type0 or Type1 can handle) for a
high % of packets, then most robust option is just to use Type 2
packets.

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. 
[Haipeng] Not sure I completely follow this. The compressor would
typically set the value of OA based upon the characteristics of "packet
drop run lengths". I'm not sure how a pt_0_crc7 helps if all OA
"updates" are dropped on the airlink. As I already mentioned in the
separate email thread, if robustness is needed, then we really need to
make sure that the compressor sends enough repetition of the updates.
Using crc7 does not help to shorten the OA length, it just helps to
increase the error detection probability by a very marginal amount as
pointed out above.

Regards,
Haipeng

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