RE: [rohc] RE: Comments on ROHCv2 profiles draft

["Jin, Haipeng" <haipengj at qualcomm.com>]

Hi, Kristofer,

Hope you have had a great vacation. Please see my comments inline. 

-----Original Message-----
From: Kristofer Sandlund (LU/EAB)
[mailto:kristofer.sandlund at ericsson.com] 
Sent: Tuesday, July 31, 2007 6:43 AM
To: Jin, Haipeng; rohc at ietf.org
Cc: Ghyslain Pelletier (LU/EAB)
Subject: RE: [rohc] RE: Comments on ROHCv2 profiles draft 

Hi Haipeng,

sorry for my even longer delay in replying, I've been on vacation for
the 
last month, so I didn't read my mail.
I'm editing the relevant parts of the mail and give some comments below.

<upwards transition>
> 
> When I read up on the old discussions we had on this, I found my old
> email from last year
> http://www1.ietf.org/mail-archive/web/rohc/current/msg04569.html
> which proposed alternatives for how to handle IR and state
> transitions, and the only reply I got on that was from Lars-Erik who
> supported the two-step approach which is why this draft version still
> uses the two-step logic. 
> 
> Could you check that one and give your opinions?
> 
> [Haipeng] In the options you listed, updating crc-8 to cover control
> field seems to be ruled out because the conflict between current value
> and new value. For this type of scenario where the control field is
> updated, wouldn't be sufficient to only cover the new value?
> 
> [Haipeng] Another simpler alternative would be to have something along
> the line of Ghyslain's proposal in his email titled "RoHCv2 Issue#2:
> Two-step transition".
> (http://www1.ietf.org/mail-archive/web/rohc/current/msg04949.html),
> basically, the decompressor should be allowed to attempt CRC3
> decompression directly following IR. 
> 

I agree with Ghyslains proposal for the upwards transitions (I prefer
"SHOULD" alternative), so if you're ok with that, I think that will be 
what goes into the next revision.

[Haipeng] I am fine with the "should" alternative.


<downwards transition> 
> 
> I prefer to leave it up to the decompressor to drop back to NC state
> whenever it wants to, as long it has reason to suspect that it might
> have lost synch of the static context. For example, if the
> decompressor receives an IR packet with a bad CRC-8 followed by a
> CRC-3 packet, 
> it might guess that it doesn't have sufficient static context and
> drop directly to NC. 
> 
> 
> [Haipeng] This is interesting, it means that the decompressor
> will treat
> crc-8 error differently to crc3 error, unlike in 3095 where the
> decompressor only counts the number of crc errors (k out of n). But I
> guess as an implementation option, it is all right.
> 

Even for 3095, the k out of n rule is just a recommendation and not any
normative text, so even there the decompressor *can* make a 1-step
downwards transition.

[Haipeng] I am talking about the following text in 4.3.2 of 3095, "
However, when that happens it first transits back to the "Static
   Context" state.  There, reception of any packet sent in the FO state
   is normally sufficient to enable transition to the "Full Context"
   state again.  Only when decompression of several packets sent in the
   FO state fails in the "Static Context" state will the decompressor go
   all the way back to the "No Context" state."

> 
> I'm not saying it should do that always, but since all the downwards
> transitions have to be based on some form of guessing by the
> decompressor, I think it is fine for the spec to say that it may be
> extra conservative if it wants to.
> But like I said, I can agree to either of the solutions.
> 
> Regarding more guidelines, do you think that section 5.3.2 is
> insufficient (we refer to that from the picture w.r.t. transitions)?
> I think that has quite good guidelines for how to detect
> context damage,
> but if you think it is insufficient, please give a text proposals
> that we can discuss further. 
> 
> 
> [Haipeng] Actually, the text in 5.3.2 seems good enough if
> you adopt the
> two-step approach. The third paragraph kind of implies that the
> transition is a two step process. So maybe just a little rewording of
> the text in 5.3.1.3 (** ** marks the new wording):
> 
> "
>    Downward transition:
> 
>       The decompressor moves back to the IC state if it
> assumes context
>       damage, and **further** back to the NC state if it
> assumes static
> context
>       damage.
> "
> 
> [Haipeng] One the other hand, if you want to allow one-step downward
> transition, then how about enhancing the third paragraph in 5.3.2 as "
> 	Validity of the context rather relates to the detection of a
> problem
>    with the context.  The decompressor first assume that the type of
>    information that most likely caused the failure(s) is the
> state that
>    normally changes for each packet, i.e. context damage of
> the dynamic
>    part of the context.  Upon repeated failures and unsuccessful
>    repairs, the decompressor then assume that the entire context,
>    including the static part, needs to be repaired, i.e.
> static context
>    damage. **Alternatively, if the decompressor detects crc-8
> failures, then it may directly assume static context failure. **" ?
> 

I would only like to mention "crc-8" as an example in that text to
avoid leading readers to believe this is the only case it may be done.
If the decompressor wants to static-nack, I think it can do this based
on basically any data that it belives is "fatal" (e.g. link layer 
knowledge). So maybe a slight modification of your proposal would work?

**Alternatively, if the decompressor is confident that the static part
of the context has become invalid (e.g. if CRC-8 validation fails),
then it may directly assume static context failure. **
[Haipeng] The text looks good to me.

Thanks,
Haipeng

/Kristofer


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

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