Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document

["Angelo P. Castellani" <[e-mail]>]

> And we have kept reserved fields. They are set to 0 and easy to
> compress, and at the same time the protocol is open to future
> extensions.

Do you believe that avoiding having defaults, bit-flagged header
parsing and in-line fields is useful for some implementations?

It's not that complex to be handled and typically is handled
successfully in very constrained devices (see 6lowpan
implementations).

I still don't get why:

a) having lots 0s in some implementations and the optional requirement
for a separate generic compression layer.
b) or in some implementation with strict power constraints, the
requirement for a separate (!!) RPL adaptation layer

could simplify, in general, RPL systems.

> Still, we have refrained to optimize for one specific type of LLN; as
> you know, LP 802.11 and recent variations of 802.15.4 support IPv6 min
> MTU.
> [...]
> Many sorts of them actually. In one extreme there can be a really
> optimized adaption layer for each type of LLN and for each given
> protocol in which case it probably makes sense to leave the work to the
> IPv6-over-foo WG. GHC is the other end of that spectrum, where we can
> get a reasonable benefit independent of the MAC and for all sorts of
> packets.

I want to clarify better my point: I am NOT advocating to have an
optimization for a specific LL.

I will prefer having in RPL something like the following text:

<<If the lower link layer has the following characteristics:

MAX_FRAME_SIZE < K

then you MUST use the shorter format X for DIO, Y for DAO, Z for Option N>>

In this way we are not bounded to a specific link layer

> Yes, that's the discussion I had hoped we'd have with this thread, and
> the reason why I support this work.

I support this work too, as long as we are not introducing the added
complexity of handling both formats for interoperability.

I would prefer that given a link layer technology having some
high-level characteristics, only one message format is permitted.

> You'll note that GHC reuses the
> 6LoWPAN context and can probably compress efficiently the costly target
> and transit options, as well as the routing header.

Definitely, reusing context information (if possible) is a very good approach.

> My own take is that it is a good start for us, and that we should study
> its applicability and then figure if/where more specific macros
> can/need-to be applied.

Sure, let's discuss about this.

Best,
Angelo