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

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

Thanks Pascal for the interesting response.

Some comments (and more questions) inline.

On Thu, Sep 1, 2011 at 16:22, Pascal Thubert (pthubert)
<[e-mail]> wrote:
> For the current features, RPL is now complete. We could have done
> smaller options but that's not the way the WG decided to go.

OK, I understand that the WG did not decided to go for a "compact"
format (everywhere).

Some questions about the design of the current message format:
1) What are the benefits of having a protocol targeting LLNs with very
big flexible base message format?
2) Wouldn't a more parsimonious packet format, more defaults, more
in-line fields be a better tradeoff?

> The idea was and is still that for a constrained environment, an
> additional compression could take place as an adaptation layer, not as a
> protocol replacement.
> This is what 6LoWPAN HC does for 802.15.4 based networks for instance.
> That approach is being extended for multiple other LLC/MACs, including
> Bluetooth and DECT.

I am not against compression work and I personally like that efforts,
such as 6LoWPAN.

However we should remember that 6LoWPAN is born as the "IPv6 over IEEE
802.15.4" whereas IPv6 targets the whole Internet and obviously
requires an adaptation layer to adapt to the various lower-layer
technologies.

The work that 6LoWPAN WG has done is very useful, and much work will
be shared (hopefully in a single document) even for different lower
layers.

However, in my understanding of ROLL, this WG is born targeting LLNs,
where short-frames and low-bandwidth is the norm rather than the
exception.

> And GHC http://tools.ietf.org/html/draft-bormann-6lowpan-ghc-02 extends
> the approach for RPL and other protocols.
>
> For me the question is really whether GHC is the final answer or if we
> should recommend something more specific to RPL, for instance adding a
> little bit of dictionary into it.
>
> If GHC appears to be the right approach, then let it be known and let us
> find a WG to host it. If we prefer a more RPL-specific compression, then
> maybe we can host it.
>
> In any fashion, I'd think that the compression needs to improve not only
> the control, but also the data packets.

In my understanding, GHC is a general purpose compression method, that
should be applied to address the fact that we can't expect that every
protocol will be redesigned or compressed to go on power-constrained
networks.

Native power-constrained protocols probably can natively get better
results by considering the fact that are being designed for such
networks.

Best,
Angelo