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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 15 Oct 2014 07:52:07 +0000

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:[email-masked]]
> Sent: mercredi 15 octobre 2014 09:23
> To: Pascal Thubert (pthubert)
> Cc: Michael Richardson; Samita Chakrabarti; Ralph Droms (rdroms);
> [email-masked]
> 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) <[email-masked]>
> 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:[email-masked]] On Behalf Of Carsten Bormann
> >> Sent: dimanche 12 octobre 2014 15:19
> >> To: Michael Richardson
> >> Cc: Samita Chakrabarti; [email-masked]; Ralph Droms (rdroms)
> >> Subject: Re: [6lo] Call for Agenda items (IETF91)
> >>
> >> On 11 Oct 2014, at 23:23, Michael Richardson <[email-masked]>
> >> 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
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/6lo
> >
> > _______________________________________________
> > 6lo mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/6lo
> >
> >

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Oct 2014 09:59:26 +0200

> b) Conservative. RPL would only consume a very limited NHC space, at the expense of one extra octet in each packet.

No, that’s not how it [1] works.

There is no extra byte except if the R or F flags in the RPL Packet Information (RPI) are non-zero.

It appears to me that those flags are an infrequent occurrence, so the total expense in bytes sent should be near zero.  There *is* expense in code size (complexity), though.

I have not been able to obtain any real world numbers on the frequency of non-zero R bits in real life RPL traffic.
(I have no idea whether non-zero F bits actually exist in real life at all.)
Those would be questions that people with more RPL experience than I have can answer.

Grüße, Carsten

[1] http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-02

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 15 Oct 2014 08:40:43 +0000

Hello Carsten:

At this moment, we can guarantee that a) and b) as presented are generally doable. This is why I called on that. People might think that b) is acceptable as presented anyway.

You are suggesting here that the extra byte in b) may apply only to some packets, but we do not have a consensus that your specific solution is acceptable and I have my own string doubts because of the way RPL uses those bits.

We can discuss this on another thread, but I'd wish to keep this call very abstract on 2 general approaches as opposed to draft-pascal vs. draft-carsten to get the rough balance of people's minds, greedy, or conservative.

Cheers,

Pascal

> Sent: mercredi 15 octobre 2014 09:59
> Cc: [email-masked]; Routing Over Low power and Lossy networks;
> [email-masked]
> Subject: Re: [6lo] Call for advice on the RFC 6553 6lo encoding
> 
> > b) Conservative. RPL would only consume a very limited NHC space, at the
> expense of one extra octet in each packet.
> 
> No, that's not how it [1] works.
> 
> It appears to me that those flags are an infrequent occurrence, so the total
> expense in bytes sent should be near zero.  There *is* expense in code size
> (complexity), though.
> 
> I have not been able to obtain any real world numbers on the frequency of
> non-zero R bits in real life RPL traffic.
> (I have no idea whether non-zero F bits actually exist in real life at all.) Those
> would be questions that people with more RPL experience than I have can
> answer.
> 
> Grüße, Carsten
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Oct 2014 11:54:58 +0200

On 15 Oct 2014, at 10:40, Pascal Thubert (pthubert) <[email-masked]> wrote:

> You are suggesting here that the extra byte in b) may apply only to some packets,

That’s not a suggestion but simply how I designed it, in order to free up the bits without increasing the packet sizes.

> but we do not have a consensus that your specific solution is acceptable

We need to have this discussion now then.  My proposal is sensible only if that is the case.

> and I have my own string doubts because of the way RPL uses those bits.

Please put those on the table…

Grüße, Carsten