[rohc] Re: [nemo] Fwd: FW: I-D ACTION:draft-minaburo-rohc-nemo-00.txt

[Greg Daley <greg.daley at eng.monash.edu.au>]

Hi Vijay,

I think there may be some value in this, if more than just the next
IPv6 header can be compressed.   If it doesn't mitigate the
NEMO MTU issue, people may not care for it.

Regarding the draft itself:

Section 2 has all of the details about ROHC compression.
For the 7 paragraphs after paragraph 2, there is not a single
explicit reference to the ROHC documents for NEMO people to
investigate.

This section, while brimming with details, seems to leave me feeling
I don't have enough ROHC context myself.  It would be good to have
diagrams illustrating which headers will be subject to compression,
and some considerations about the NEMOs themselves (apart from the
10 lines in the first, second and last paragraph of the section).
After all, it is called:  "The use of ROHC in NEMO"

Apart from that, it seems like a good idea in general,
not just for NEMO.  It seems like a MIPv6 HA/MAP/FMIPv6AR issue
too, although the addresses in the upper layer tunnel have more
constrained destinations in the non-router case.


I didn't see any text about packet reordering in the document.
I'd guess that the Internet is about the most likely point-to-point
medium to re-order packets.

Vijay Devarapalli wrote:
> In general, I like the the idea of using ROHC in the tunnel between
> the mobile router and the home agent, to reduce the tunnel overhead.
> I would like to see this draft standardized.
>
> one quick comment.
>
> > As the addresses are classified as static, each time the MR changes 
> > its attachment point the ROHC context will be initialized.
>
>
> wonder why? the MR could just send a binding update to the HA from
> the new CoA. binding updates are sent reliably. when the HA processes
> the binding update, its updates the ROHC context with the new CoA.
> once the MR receives a binding acknowledgement which shows success
> status, it also updates the local ROHC context with the new CoA.

Actually, I'm not sure that the draft text itself was accurate.

If addresses INSIDE the tunnel changed, then there would have to be
changes to the binding or to the context.

Why would there need to be changes to the context if the transporting
tunnel endpoint addresses - the outer addresses (which aren't subject
to compression) change?

The data transferred on the tunnel doesn't change because of the CoA
change.

I'd like to see this document develop maybe as informational
if no NEMO-specific protocol issues arise.

Greg

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