[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
<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.
>
> 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. **
/Kristofer
_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc