Subject: [6lo] ascertaining RPL compression mechanism way forward

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 16 Apr 2015 20:28:19 +0000

Dear authors of [1] and [2],

[1] https://tools.ietf.org/html/draft-thubert-6lo-rpl-nhc/
[2] https://tools.ietf.org/html/draft-thubert-6lo-routing-dispatch/

During the RPL compression mechanism discussion at the recent IETF meeting in Dallas, there was an emerging position which we'd like to ascertain. The authors and the WG seemed to gravitate away from NHC++ (a possible extension of [1]) as the path forward. Instead, the sentiment in the room was to focus on the DISPATCH header approach [2], regardless of whether the Mesh Header could be reclaimed or whether the Escape mechanism had to be used.

As authors of these documents, do you agree that dropping NHC++ (based on [1]) represents your current thinking?

Furthermore, it seems like going forward you would rather focus on the dispatch solution (based on [2]) even if this means using the ESC and paying the cost (an extra byte, correct?).

In a discussion among the chairs, James and Ralph, we noted that *if* you were ok with moving forward with the ESC approach, this would simplify the process tremendously. Reclaiming the Mesh Header entirely or partially is something that entails the liaison queries to other SDO's and would incur very careful and critical scrutiny from the IESG. The liaisons have not yet gone out, so before we launch that very involved process (with uncertain ending and results) we would like to double-check if you could would be willing to live with an ESC-based Dispatch solution. This could be dealt with internally to the WG and to the IETF, of course, and would be a much more controlled and simple process.

Thanks,

Samita, James, Ralph and Gabriel

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 17 Apr 2015 09:17:53 +0000

Hello Gabriel:

Yes to all on my side, you are 100% clear and correct.
My suggestion, then, is to republish using the escape, thus consuming an additional byte, but still in the background see if we can save it.
Going to RFC will probably take a long time and we can keep that particular option open till the end, in case work with the other SDOs turn out positively.
One remark is that the other SDOs might embrace the new spec in the future, and if they do, today's reluctance would become tomorrow's cost.

What do others think ?

Pascal

From: 6lo [mailto:[email-masked]] On Behalf Of Gabriel Montenegro
Sent: jeudi 16 avril 2015 22:28
To: [email-masked]; [email-masked]
Cc: Samita Chakrabarti; James Woodyatt ([email-masked]); Ralph Droms; [email-masked]
Subject: [6lo] ascertaining RPL compression mechanism way forward

Thanks,

---

From: Robert Cragie <[email-masked]>
Date: Fri, 17 Apr 2015 10:55:46 +0100

Hi Pascal and Gabriel,

I agree with the approach Pascal outlines below and also agree that we 
should drop NHC++.

Robert

On 17/04/2015 10:17, Pascal Thubert (pthubert) wrote:
> My suggestion, then, is to republish using the escape, thus consuming 
> an additional byte, but still in the background see if we can save it.
>
> Going to RFC will probably take a long time and we can keep that 
> particular option open till the end, in case work with the other SDOs 
> turn out positively.
>
> One remark is that the other SDOs might embrace the new spec in the 
> future, and if they do, today’s reluctance would become tomorrow’s cost.
>
> What do others think ?
>
> Pascal
>
> *From:*6lo [mailto:[email-masked]] *On Behalf Of *Gabriel Montenegro
> *Sent:* jeudi 16 avril 2015 22:28
> *To:* [email-masked]; 
> [email-masked]
> *Cc:* Samita Chakrabarti; James Woodyatt ([email-masked]); Ralph 
> Droms; [email-masked]
> *Subject:* [6lo] ascertaining RPL compression mechanism way forward
>
> <https://tools.ietf.org/html/draft-thubert-6lo-rpl-nhc/>
>
> During the RPL compression mechanism discussion at the recent IETF 
> meeting in Dallas, there was an emerging position which we’d like to 
> ascertain. The authors and the WG seemed to gravitate away from NHC++ 
> (a possible extension of [1]) as the path forward. Instead, the 
> sentiment in the room was to focus on the DISPATCH header approach 
> [2], regardless of whether the Mesh Header could be reclaimed or 
> whether the Escape mechanism had to be used.
>
> As authors of these documents, do you agree that dropping NHC++ (based 
> on [1]) represents your current thinking?
>
> Furthermore, it seems like going forward you would rather focus on the 
> dispatch solution (based on [2]) even if this means using the ESC and 
> paying the cost (an extra byte, correct?).
>
> In a discussion among the chairs, James and Ralph, we noted that 
> **if** you were ok with moving forward with the ESC approach, this 
> would simplify the process tremendously. Reclaiming the Mesh Header 
> entirely or partially is something that entails the liaison queries to 
> other SDO’s and would incur very careful and critical scrutiny from 
> the IESG. The liaisons have not yet gone out, so before we launch that 
> very involved process (with uncertain ending and results) we would 
> like to double-check if you could would be willing to live with an 
> ESC-based Dispatch solution. This could be dealt with internally to 
> the WG and to the IETF, of course, and would be a much more controlled 
> and simple process.
>
> Thanks,
>
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Apr 2015 13:46:19 +0200

I completely agree with this approach, except that I have no idea where
"ESCAPE" comes in.

RFC 4944 says:

         | 01  111111 | ESC        - Additional Dispatch byte follows |

I don't think we need an additional dispatch byte.  We just may have to
be more sparse in allocating bits in the dispatch byte than we could be
by executing on the Mesh Header renovation.

Grüße, Carsten

Pascal Thubert (pthubert) wrote:
> My suggestion, then, is to republish using the escape, thus consuming an
> additional byte, but still in the background see if we can save it.
> 
> ascertain. The authors and the WG seemed to gravitate away from NHC++ (a
> possible extension of [1]) as the path forward. Instead, the sentiment
> in the room was to focus on the DISPATCH header approach [2], regardless
> of whether the Mesh Header could be reclaimed or whether the Escape
> mechanism had to be used.
> 
>  
> 
> In a discussion among the chairs, James and Ralph, we noted that **if**
> you were ok with moving forward with the ESC approach, this would
> simplify the process tremendously. Reclaiming the Mesh Header entirely
> or partially is something that entails the liaison queries to other
> SDO’s and would incur very careful and critical scrutiny from the IESG.
> The liaisons have not yet gone out, so before we launch that very
> involved process (with uncertain ending and results) we would like to
> double-check if you could would be willing to live with an ESC-based
> Dispatch solution. This could be dealt with internally to the WG and to
> the IETF, of course, and would be a much more controlled and simple process.
> 
>  
> 
> Thanks,
> 
>  
>

---

From: James Woodyatt <[email-masked]>
Date: Fri, 17 Apr 2015 10:00:49 -0700

>          | 01  111111 | ESC        - Additional Dispatch byte follows |

We can't redefine the Mesh Header without going through the Liaison
Statements and the "careful IESG scrutiny" that Gabriel mentioned.

We can still use the method described in I-D.thubert-6lo-routing-dispatch,
while avoiding the Liaison Statements and the IESG scrutiny, if we dispense
with redefining the Mesh Header, and instead we use a third of the dispatch
codes available in the range 64 to 255, which are available at the cost of
an additional octet by using the ESC dispatch code [redefined in RFC 6282
as 01000000].

> by executing on the Mesh Header renovation.

It would be interesting to see a revision of
I-D.thubert-6lo-routing-dispatch describing how to compress RPL artifacts
without A) redefining the Mesh Header, B) requiring use of the Dispatch
Header ESC code, and C) consuming too many of the dispatch code points
currently reserved for future use [1].

[1]
http://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml#_6lowpan-parameters-1

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: James Woodyatt <[email-masked]>
Date: Fri, 17 Apr 2015 10:17:16 -0700

On Fri, Apr 17, 2015 at 10:00 AM, James Woodyatt <[email-masked]> wrote:

> [...] use a third of the dispatch codes available in the range 64 to 255,
> which are available at the cost of an additional octet by using the ESC
> dispatch code [redefined in RFC 6282 as 01000000].
>

Correction: I can imagine a way to update RFC 6282 so that new dispatch
codes are allocated from 64 to 319 provided that one of those codes is
consumed as another escape for dispatch codes >= 320.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 17 Apr 2015 15:18:14 -0400

> On Apr 17, 2015, at 7:46 AM 4/17/15, Carsten Bormann <[email-masked]> wrote:
> 

The plan would be to consume the Dispatch header code points currently marked as "reserved for future use" in the IANA "Dispatch Type Field" registry for new compression methods?

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Fri, 17 Apr 2015 15:20:41 -0400

Can someone explain to me, in words of one syllable or fewer :-), why the RPL header compression is not possible in NHC or why it is in some way better to use the Dispatch header?

- Ralph

> On Apr 17, 2015, at 5:55 AM 4/17/15, Robert Cragie <[email-masked]> wrote:
> 
> Hi Pascal and Gabriel,
> 
> I agree with the approach Pascal outlines below and also agree that we should drop NHC++.
> 
> Robert
> 
>> One remark is that the other SDOs might embrace the new spec in the future, and if they do, today’s reluctance would become tomorrow’s cost.
>>  
>> What do others think ?
>>  
>> Pascal
>>  
>> During the RPL compression mechanism discussion at the recent IETF meeting in Dallas, there was an emerging position which we’d like to ascertain. The authors and the WG seemed to gravitate away from NHC++ (a possible extension of [1]) as the path forward. Instead, the sentiment in the room was to focus on the DISPATCH header approach [2], regardless of whether the Mesh Header could be reclaimed or whether the Escape mechanism had to be used.
>>  
>> In a discussion among the chairs, James and Ralph, we noted that *if* you were ok with moving forward with the ESC approach, this would simplify the process tremendously. Reclaiming the Mesh Header entirely or partially is something that entails the liaison queries to other SDO’s and would incur very careful and critical scrutiny from the IESG. The liaisons have not yet gone out, so before we launch that very involved process (with uncertain ending and results) we would like to double-check if you could would be willing to live with an ESC-based Dispatch solution. This could be dealt with internally to the WG and to the IETF, of course, and would be a much more controlled and simple process.
>>  
>> Thanks,
>>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Apr 2015 23:01:45 +0200

On 17 Apr 2015 at 21:21:52, Ralph Droms ([email-masked]) wrote:
Can someone explain to me, in words of one syllable or fewer :-), why the RPL header compression is not possible in NHC or why it is in some way better to use the Dispatch header? 
RPL header compression is possible just fine in NHC; the current drafts show how.

The issue is whether the various hacks that are needed to put the forwarding information into the IP headers (IP-in-IP, routing headers, hop-by-hop options) are worth it.  It seems to me that, after RPL has demonstrated the whole complexity of doing this, the excitement about the ostensible architectural purity of this approach has waned a bit.

(Sorry, too many multisyllabic words.)

The tipping point may have been the attempts to reasonably compress RFC 6554.  The information saved in the routing header by just moving forward the pointer at each hop is useless in a non-storing RPL mesh.  So why stick to IP's routing header architecture?

Grüße, Carsten

---

From: Ralph Droms <[email-masked]>
Date: Fri, 17 Apr 2015 17:14:40 -0400

> On Apr 17, 2015, at 5:01 PM 4/17/15, Carsten Bormann <[email-masked]> wrote:
> 
>> 

Right.

> The issue is whether the various hacks that are needed to put the forwarding information into the IP headers (IP-in-IP, routing headers, hop-by-hop options) are worth it.  It seems to me that, afte…

Do you mean the IP-in-IP overhead for for carrying the extra headers required by RPL (RH3 and RPL hop-by-hop)?

I'm not meaning to pick nits; rather I want to have a precise understanding of what is being compressed, what is being elided and the resulting compression savings (I'll re-read the latest rev of the doc after I send this message).

> (Sorry, too many multisyllabic words.)

I'll try to keep up...
> The tipping point may have been the attempts to reasonably compress RFC 6554.  The information saved in the routing header by just moving forward the pointer at each hop is useless in a non-storing…

Because we're trying to use IP?  I'm not meaning to be glib or snarky.  I'm asking an honest question: are the methods in routing-dispatch IP compression or use of a layer used by a 6LoWPAN mesh to deliver IP?

- Ralph

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Apr 2015 23:19:56 +0200

Do you mean the IP-in-IP overhead for for carrying the extra headers required by RPL (RH3 and RPL hop-by-hop)? 
The prohibitive overhead is compressed away reasonably.  Mounting all this stuff into IP headers that are somewhat averse to be used this way is, however, not as architecturally clean as once thought.

Because we're trying to use IP? I'm not meaning to be glib or snarky. I'm asking an honest question: are the methods in routing-dispatch IP compression or use of a layer used by a 6LoWPAN mesh to deliver IP? 
I believe the answer is yes.

(Which subanswer you arrive at depends on your viewpoint — there is something like a particle-wave style duality here.)

Grüße, Carsten

---

From: Ralph Droms <[email-masked]>
Date: Fri, 17 Apr 2015 17:28:09 -0400

Backing up a bit...

> On Apr 17, 2015, at 5:19 PM 4/17/15, Carsten Bormann <[email-masked]> wrote:
> 

So one advantage of using the Dispatch header is to bypass some architectural requirements of IPv6 that would be imposed by using the NHC header?

> (Which subanswer you arrive at depends on your viewpoint — there is something like a particle-wave style duality here.)

I'm going to hold off on picking which subanswer I think gets a "yes" until I reread routing-dispatch.  

- Ralph

---

From: Gabriel Montenegro <[email-masked]>
Date: Fri, 17 Apr 2015 21:34:13 +0000

I think some of the confusion is that none of this has been fully spelled out. Having 2 or 3 folks understand that this could be done is not enough (it may not even guarantee that those 2 or 3 folks have exactly the same mechanisms in mind). Could the RPL compression folks issue a new draft of dispatch with the ESC mechanism (and whatever else is needed) fully spelled out?

---

From: Ralph Droms <[email-masked]>
Date: Fri, 17 Apr 2015 17:47:32 -0400

> On Apr 17, 2015, at 5:34 PM 4/17/15, Gabriel Montenegro <[email-masked]> wrote:
> 

I think such a revision would be very helpful.

> The tipping point may have been the attempts to reasonably compress RFC 6554.  The information saved in the routing header by just moving forward the pointer at each hop is useless in a non-storing…

It would be very helpful to me to have a clear explanation of the changes to the IP header architecture represented by the methods in routing-dispatch; bonus points for motivations.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Fri, 17 Apr 2015 17:51:36 -0400

- Ralph

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 20 Apr 2015 08:01:12 +0000

Hello Ralph:

My short answer is pure cost. 

The whole point of this compression is MAC headers of 127 byes in 802.15.4, and even less in some other networks, down to 27 bytes for BTLE , and even less at the lowest rates of LPWA solutions such as LoRa.
Whether 6LoWPAN is adopted and usable over a certain technology may depend on one byte or two. I've been there with ISA100.11a.

So cost wise: we figured that the greedy NHC is no way to go if we add more stuff, so we need an additional byte in the NHC, which was one of the propositions in Hawaii. Starting from that, even if we use the escape dispatch, we're still even.

And then the RPI does a much better job at compressing the outter IP header than IPHC, that's because we know that source or destination is the root, and that the other is often duplicated in the inner header, so we can encode that.

There are a number of other good reasons to go 6LoRH, though:
- good separation of router and host operations. The routers care for the 6LoRH, the plain host does not.
- possibility for the last RPL router to strip RPL artifacts before delivery to a legacy host in a simple manner
- no update/extension to RFC 6282. The code that parses the inner IP packet is unchanged and still complete, good for code stability, saves re-interop.
- opens a whole new space for new applications (e.g. BIER and Bloom-based variations)

Cheers,

Pascal

> -----Original Message-----
> From: 6lo [mailto:[email-masked]] On Behalf Of Ralph Droms
> Sent: vendredi 17 avril 2015 21:21
> Cc: Samita Chakrabarti; Gabriel Montenegro; James Woodyatt
> ([email-masked]); [email-masked] WG
> Subject: Re: [6lo] ascertaining RPL compression mechanism way forward
> 
> Can someone explain to me, in words of one syllable or fewer :-), why the RPL
> header compression is not possible in NHC or why it is in some way better to use
> the Dispatch header?
> 
> - Ralph
> 
> >> Going to RFC will probably take a long time and we can keep that particular
> option open till the end, in case work with the other SDOs turn out positively.
> >> One remark is that the other SDOs might embrace the new spec in the future,
> and if they do, today's reluctance would become tomorrow's cost.
> >>
> >> What do others think ?
> >>
> >> Pascal
> >>
> >> During the RPL compression mechanism discussion at the recent IETF meeting
> in Dallas, there was an emerging position which we'd like to ascertain. The
> authors and the WG seemed to gravitate away from NHC++ (a possible
> extension of [1]) as the path forward. Instead, the sentiment in the room was to
> focus on the DISPATCH header approach [2], regardless of whether the Mesh
> Header could be reclaimed or whether the Escape mechanism had to be used.
> >>
> dispatch solution (based on [2]) even if this means using the ESC and paying the
> cost (an extra byte, correct?).
> >>
> >> In a discussion among the chairs, James and Ralph, we noted that *if* you
> were ok with moving forward with the ESC approach, this would simplify the
> process tremendously. Reclaiming the Mesh Header entirely or partially is
> something that entails the liaison queries to other SDO's and would incur very
> careful and critical scrutiny from the IESG. The liaisons have not yet gone out, so
> before we launch that very involved process (with uncertain ending and results)
> we would like to double-check if you could would be willing to live with an ESC-
> based Dispatch solution. This could be dealt with internally to the WG and to the
> IETF, of course, and would be a much more controlled and simple process.
> >>
> >> Thanks,
> >>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 20 Apr 2015 08:13:37 +0000

Dear all

> > I think some of the confusion is that none of this has been fully spelled out.
> Having 2 or 3 folks understand that this could be done is not enough (it may not
> even guarantee that those 2 or 3 folks have exactly the same mechanisms in
> mind). Could the RPL compression folks issue a new draft of dispatch with the
> ESC mechanism (and whatever else is needed) fully spelled out?
> 

On it, out there real soon

> 
> Carsten wrote:
> 
> > The tipping point may have been the attempts to reasonably compress RFC
> 6554.  The information saved in the routing header by just moving forward the
> pointer at each hop is useless in a non-storing RPL mesh.  So why stick to IP's
> routing header architecture?
> 
> It would be very helpful to me to have a clear explanation of the changes to the
> IP header architecture represented by the methods in routing-dispatch; bonus
> points for motivations.

The initial goal was no change. Just a reversible formatting between a compressed and an uncompressed packet. Noting that a packet can be fragmented so you need all fragments to rebuild the packet.

Then we have that idea that the outer routing header could be placed before the fragment header, allowing to route fragment like you can forward them in mesh under. Noting that this does not solve the main problems with forwarding fragments. Forwarding fragments yields issues like lack of loss discovery and retry, co-channel interference between adjacent fragments, congestion in intermediate nodes due to multiple streams, bloat when there are more fragments than intermediate nodes, whether you do it at L2 or L3 - or L2.5 like in my fragment recovery draft.

The proposal lead to a whole lot of confusion on top of your architectural question. Talking with the chairs in Dallas, we figured that we should probably eliminate that mode for the time being. I'll do that in the revision as well.

Cheers,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 20 Apr 2015 10:12:13 +0000

Dear all

I agree with Carsten that we can also try something in the current whitespace:

Please find an example of both approaches in https://bitbucket.org/6lo/rpi/src/master/draft-thubert-6lo-routing-dispatch-04.txt 

Cheers,

Pascal

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: vendredi 17 avril 2015 13:46
> To: Pascal Thubert (pthubert)
> Cc: Gabriel Montenegro; [email-masked];
> [email-masked]; Samita Chakrabarti; James Woodyatt
> ([email-masked]); Ralph Droms; [email-masked]
> I don't think we need an additional dispatch byte.  We just may have to be more
> sparse in allocating bits in the dispatch byte than we could be by executing on
> the Mesh Header renovation.
> 
> Grüße, Carsten
> 
> 
> > other SDO’s and would incur very careful and critical scrutiny from the IESG.
> > Dispatch solution. This could be dealt with internally to the WG and
> > to the IETF, of course, and would be a much more controlled and simple
> process.
> >
> >
> >
> > Thanks,
> >
> >
> >