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

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

Hi, Kristofer,

Sorry for the long delay in reply, I was out of office without email
access for a few days. Please see more comments inline.

-----Original Message-----
From: Kristofer Sandlund (LU/EAB)
[mailto:[e-mail]] 
Sent: Monday, June 18, 2007 11:49 PM
To: Jin, Haipeng; [e-mail]
Cc: Ghyslain Pelletier (LU/EAB)
Subject: RE: [rohc] RE: Comments on ROHCv2 profiles draft 

Hi Haipeng,

thanks for the feedback, more comments inline.

Jin, Haipeng <mailto:[e-mail]> wrote on den 19 juni 2007
03:10 :

> Hi, Kristofer,
> 
> Thanks for your reply, please see more comments following yours.
> 
> -----Original Message-----
> From: Kristofer Sandlund (LU/EAB)
> [mailto:[e-mail]]
> Sent: Friday, June 15, 2007 1:26 AM
> To: Jin, Haipeng; [e-mail]
> Cc: Ghyslain Pelletier (LU/EAB)
> Subject: [rohc] RE: Comments on ROHCv2 profiles draft
> 
> Hi Haipeng,
> 
> comments inline as usual.
> 
> Jin, Haipeng <mailto:[e-mail]> wrote on den 15 juni 2007
> 07:05 : 
> 
>> Hi, Kristofer and Ghyslain,
>> 
>> Great effort in updating the profile draft!
>> 
>> I have the following comments:
>> 1. Decompressor state:
>> I remember we had some discussion on the state diagram in
>> section 5.3.1.
>> It is not possible to transit from NC to FC directly. The
>> main reason is
>> that IR-DYN carries CRC-8 but does not verify the entire context so a
>> CRC-7 packet such as co-common or p0-crc7 is needed as an
>> intermediate step. Now that IR-DYN is removed, I would propose to
>> change the stage diagram to allow direct transition from NC to FC
>> with CRC-8 verification.
> 
> The IR packet has the same potential issue as the IR-DYN packet, i.e.
> that it may omit control fields from the packet and these do not get
> verified by the CRC-8. Therefore, I think the 2-step
> transition is still
> a valid choice.
> The alternative is still to try to beef up the IR
> by either adding an extra CRC or mandating the presence of control
> fields etc, but I think that's going to be a lot more "patch-work"
> (and more overhead) than having a 2-step transition which is simple.
> And the cost
> is quite minimal since you're not going to be in NC state very often.
> 
> I would have liked to change the coverage of the existing CRC-8 for
> the IR, but since that is defined by the framework, that's not an
> option, unfortunately.
> 
> [Haipeng] The framework only says the coverage of CRC-8 for IR is
> profile-dependent and recommends what is the minimal that need to be
> covered. If you think there are fields that need to be covered in
> RTP/UDP/... profiles, wouldn't it be great to list them out and have a
> discussion here and maybe make the coverage mandatory in
> these profiles?

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.


Btw, you're absolutely right that the IR CRC-8 coverage is 
profile-dependent.
I don't know where I got the other idea from, so that possibility is
also listed in the referenced mail above :)

> 
> Anyway, note that section 5 is informative, so if an implementation
> wants to do something else such as a one-step approach, that would not
> be illegal, although it is not the main recommendation of this spec
> 
> [Haipeng] The problem is that the text gives the impression that only
> two-step transition is allowed. For example, if no CRC7 is received
> in-between crc8 and crc3 packets, the decompressor will not attempt
> decompression on those crc3 packets.
> If both options are allowed, then
> it would be great if the text can be clarified to convey the idea. I
> understand that it might be hard to express all possibilities in the
> diagram before making it appear messy, maybe an alternative is to make
> the diagram simpler. Instead of showing all transition possibilities
> which are not currently done as you pointed out, the diagram can show
> only the three available states and general transition
> connections. The
> text can be enhanced to capture all the conditions.

Yes, as Rohit pointed out, there is something missing here w.r.t. the
two-step transition. I'm not exactly sure on what's the best way to
fix this, but probably add some normative rules in section 6.

> 
>> I still don't see how the two-step upward
>> transition helps
>> to make the decompression process more robust. Actually, it may make
>> things worse in some cases, for example, if the compressor sends a
>> couple of IRs, followed by a couple of p0-crc7 and then a
>> number of crc3
>> packets. If the p0-crc7 packets are erases and the
>> decompressor stays in
>> IC, all the subsequent crc3 packets will be dropped even without
>> decompression attempt when those packets can actually be decompressed
>> successfully. This is even worse if the compressor is working in
>> non-feedback mode.
> 
> As stated above, there's a larger chance of things going wrong with
> the one-step approach. And since we're using the optimistic approach,
> the chance of losing all pt-0-crc7 (as in your example above) that you
> send should be very small, otherwise the compressor has chosen a bad
> optimistic approach value. 
> 
> [Haipeng] The reason I gave this example is because in the past email
> threads, similar examples (IR re-ordering followed by crc3
> packets) were
> used to show why two-step transition is needed. I agree that if the
> compressor can choose a good OAA value, then neither that
> example nor my
> example will be a concern. One-step approach won't have
> problem either.
> 
>> 
>> Another question I have regards decompressor state is: in section
>> 5.3.1.3, the text says "The decompressor moves back to the IC state
>> if it assumes context damage, and back to the NC state if it
>> assumes static
>> context damage." about downward transition, this is not
>> consistent with
>> the diagram. So what is the real intend here? Are you
>> thinking to allow
>> direct transition back from FC to NC?
> 
> Agreed, the text and the picture are inconsistent. I would probably
> prefer adding an extra arrow to the picture, but I think the other
> option is also viable. What's you opinion?
> 
> [Haipeng] RFC3095 only discussed two-step downward transition, " 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 don't see much problem allowing
> transition back
> from FC to NC, but it would be great if there are some general
> guidelines on what might be the criteria for the decompressor to
> determine whether to go from FC to IC or from FC to NC. Do
> you have some
> scenarios in mind?

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.


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. **" ?


> 
>> 
>> 2. IP-ID behavior
>> 
>> The new profile only allows sequential behavior to inner
>> IP-ID. For all
>> outer headers, IP-IDs are assumed to be either constant or
>> random. This
>> means that in two-level IP headers (e.g. MIP) case which may
>> be a common
>> use case in wireless networks, the compressor may not be able to
>> compress the packet as efficiently as in RFC3095. It would be great
>> if you can add an sequential indicator for the outer header to
>> handle at least this case.
> 
> Here, I refer to the motivations in the now-expired requirements draft
> that this WG agreed on for ROHCv2, see section 2.6 of this one:
> http://tools.ietf.org/html/draft-ietf-rohc-rfc3095bis-improvements-03
> 
> So I would be very much against changing this since that adds a lot
> of complexity and it gives a very minimal gain and only for a very
> small subset of tunneled packets.
> 
> [Haipeng] I would be careful in saying that tunneled packets
> belong to a
> very small subset. MIP is a mobility management mechanism that is used
> widely. Tunnel packets with two levels of headers are common if CCoA
> mode of operation is used and it is important for ROHC to handle them
> efficiently. 
> 
> [Haipeng] In addition, the text in the expired requirements draft says
> that it is unrealistic that the outer IP-ID can be compressed
> sequentially. This is not true either. There are actually
> implementations where the tunneling endpoints set outer IP-ID to the
> same as inner IP-ID sequentially to allow efficient compression using
> 3095. If the same stacks are used for updated profile, the IP-ID will
> not be compressed efficiently.

Sure, there are tunnels that use such a mechanism, but however you cut
it,
tunneled packets are a subset of all packets, and tunnels with the
behavior
you describe are a subset of tunnels which means this is a minority
of packets that are affected. And the cost of 0-2 bytes in those cases 
seems small enough to avoid trying to optimize.

[Haipeng] I don't know exactly how to quantify whether the CCoA MIPv4
case is a common behavior or not. We can always argue one way or the
other. All I want to point out is that the rationale given in the
expired draft to remove outer IP-ID compression support is not really
accurate. I will wait to see whether there are others on the list
sharing the same concern.

The outer-IPID mechanism of 3095 has really been despised by
implementers
due to its strange and over-complex logic and it would require quite a
large change in the current v2 packet formats to get that back.

So I think you will need very strong motivations to get that change into
the spec, especially with previous WG consensus of not doing this (also,
ROHC-TCP already follows the IPID logic used in v2). 

/Kristofer

> 
> 
> Best Regards,
> Haipeng
> 
>> 
>> 3. Packet formats
>> 
>> I have similar concerns as Rohit on the packet formats and bit number
>> allocations and will try to follow your response on the
>> existing thread.
> 
> Ok, since that's a bit more complex issue, I will get back to
> that when
> I have had more time to prepare a comprehensive answer and re-read all
> the old discussions we had last year.
> 
> BR,
>    Kristofer
> 
>> 
>> That is for now.
>> 
>> Best Regards,
>> Haipeng
> 
> _______________________________________________
> Rohc mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/rohc

_______________________________________________
Rohc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rohc