[Roll] Call for advice on the RFC 6553 6lo encoding

Dear all,

I'm attaching below a mail from Carsten which summarizes the only point of contention that we still have in our discussion on how to compress the RPL Information in 6lo. As Carsten explains below, we need advice from the list on which approach we should be taking, and we are now calling for advice.

There are basically 2 approaches:
a) Greedy. RPL would consume a high code in the NHC space, which can be interpreted as 1/4 of its addressing capability. This would be leaving more than half available for future use.
b) Conservative. RPL would only consume a very limited NHC space, at the expense of one extra octet in each packet.

We have to choose between protecting resources now (frame size, energy) or in the future (NHC encodingspace):
a) optimizes for today's RPL-routed data packets at a time when frame size is a major issue, mostly with 802.15.4-2006 and ultra-low-speed networks (PLC, LPWA).
b) optimizes for a future when we deploy new services and routing protocols in LLNs, which will require new IPv6 options headers, and the space left in the NHC encoding becomes an issue.

Please help us and post advice, indicating whether you favor a) greedy or b) conservative, and for which technical reason.

We need to extract an initial consensus and publish a proposed solution I-draft by the cut-off on the 27, preferably earlier than that. 

Thanks a bunch in advance,

Pascal

> -----Original Message-----
> From: Carsten Bormann [mailto:cabo@tzi.org]
> Sent: mercredi 15 octobre 2014 09:23
> To: Pascal Thubert (pthubert)
> Cc: Michael Richardson; Samita Chakrabarti; Ralph Droms (rdroms);
> 6lo@ietf.org
> Subject: Re: [6lo] Call for Agenda items (IETF91)
> 
> Hi Pascal,
> 
> as I said previously [1], I wrote my version of the draft both to focus on the
> solution that we actually need to standardize and to reduce the codepoint
> footprint.  There certainly is no point in having two drafts here, so I'm ready
> to merge.  The "executive summary" of the open technical question is:
> 
> 1)
> Are we ready to allocate 1/4 of the NHC code space to RFC 6553 compression
> (knowing that RFC 6554 compression is the next thing we probably want to
> tackle)?
> 
> 2)
> And, if we aren't ready to do this, is the "escape code" approach of my draft
> [2] the right one to be more skimpy on code point space?
> 
> 
> Grüße, Carsten
> 
> [1] https://www.ietf.org/mail-archive/web/6lo/current/msg00693.html
> [2] http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-02
> 
> On 15 Oct 2014, at 08:41, Pascal Thubert (pthubert) <pthubert@cisco.com>
> wrote:
> 
> > Hello Carsten and Laurent:
> >
> > I'm happy that we are rapidly converging. Certainly, our great progress
> helped a lot the call we are making at 6TiSCH to focus on a 6lo-based
> approach.
> >
> > My quick reading is that the differences are now very minor. I think we are
> ready to document them as an executive summary, and ask for a feedback
> on the ML. If we do so rapidly, we may be able to publish a common
> document that would focus on the solution, so as to call for adoption in
> Hawaii.
> >
> > Does that work?
> >
> > Pascal
> >
> >
> >> -----Original Message-----
> >> From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Carsten Bormann
> >> Sent: dimanche 12 octobre 2014 15:19
> >> To: Michael Richardson
> >> Cc: Samita Chakrabarti; 6lo@ietf.org; Ralph Droms (rdroms)
> >> Subject: Re: [6lo] Call for Agenda items (IETF91)
> >>
> >> On 11 Oct 2014, at 23:23, Michael Richardson <mcr+ietf@sandelman.ca>
> >> wrote:
> >>
> >>>              A compression mechanism for the RPL option
> >>>                     draft-thubert-6lo-rpl-nhc-01
> >>
> >> To make this discussion more interesting, I just submitted my version
> >> of this draft as
> >>
> >> 	draft-bormann-6lo-rpl-mesh-02
> >>
> >> Htmlized:       http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-02
> >> Diff:           http://www.ietf.org/rfcdiff?url2=draft-bormann-6lo-rpl-mesh-
> 02
> >>
> >> This is slightly less efficient for common cases than
> >> draft-bormann-6lo-rpl-
> >> mesh-01 was, but makes use of the NHC idea in draft-thubert-6lo-rpl-nhc-
> 01.
> >> The main reason I am submitting this is to avoid the extensive
> >> consumption of NHC code points that is proposed by draft-thubert-6lo-
> rpl-nhc-01.
> >>
> >> Grüße, Carsten
> >>
> >> _______________________________________________
> >> 6lo mailing list
> >> 6lo@ietf.org
> >> https://www.ietf.org/mailman/listinfo/6lo
> >
> > _______________________________________________
> > 6lo mailing list
> > 6lo@ietf.org
> > https://www.ietf.org/mailman/listinfo/6lo
> >
> >