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

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

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?

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.  

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

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


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