[rohc] RE: Comments on ROHCv2 profiles draft

["Kristofer Sandlund (LU/EAB)" <[e-mail]>]

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.

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

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

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

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

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