Subject: [6lo] Some observations and suggestions regarding 6LoWPAN interoperability

From: Hudson Randal Ayers <[email-masked]>
Date: Mon, 14 May 2018 04:48:56 +0000

Hi all,

My name is Hudson Ayers and I am an Electrical Engineering PhD student at Stanford. Over the past few months I have been doing research on the Tock embedded operating system which included developing a 6LoWPAN implementation for the OS, with the help of several others. In the process of doing so, we ran into several areas for which we felt as though certain aspects of the 6LoWPAN protocol (RFC 4944/6282/6775) complicated our implementation. To learn more about this, we ended up investigating several other open source 6LoWPAN stacks, observing how they handled the intricacies of the protocol, and attempting to determine the extent to which each could be expected to interoperate with the others.

We documented our findings in the attached paper, along with several suggestions which we hypothesize might ease the burden on developers implementing the protocol and improve the likelihood of interoperability between diverse implementations. This paper was submitted to ACM SenSys 2018, and while the notification of paper acceptance is not for several months we figured that this paper might interest the members of this mailing list.

We would love to hear what everyone thinks - any and all feedback is appreciated.

Thanks,

Hudson Ayers

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 15 May 2018 08:22:46 +0200

Hi Hudson,

interesting research!

Kudos for making this available while it is still officially stuck in some lengthy review process.

I can’t say I have processed all the details in the paper, but I would like to point to one need that we have in maintaining a protocol that has been around for a decade: It is not always useful to say “B would have been better than A” — we are much more interested in ways to get from a deployed A to a deployed B.  Sometimes that transition negates all of the positive effects that opting for B would have had in the first place; sometimes the transition is just hard to engineer so it stays beneficial.

One example of “B would have been better than A” is uncompressed mode.  6LoWPAN includes that packet format because it seemed simple.  Of course, compressed mode is also mandatory, and is what actually gets used (it is so much more efficient).  When we finally ran a formal interop in 2013, we were shocked to find out that more than half of the interop problems were with the “simple” uncompressed mode!  Having a rarely executed “simple” mode in addition to the one that gets tested and debugged was a big mistake.  This was corrected in the 6lo ports to other radios (by simply not including uncompressed mode), but is hard to fix for the original 6LoWPAN, where, as you note, some implementations gratuitously send uncompressed mode.

In hindsight, we probably should have worked on generating a formal deprecation notice for uncompressed mode in 2013; by now, most implementations would have been fixed.

I’m not sure I understand your capability classes.  Today, an implementation does not have to know what the compressor of the peer actually supports — it just has to be able to decompress, which is a non-trivial, but limited amount of code.  Creating capability classes that restrict what the compressor is allowed to do with any specific decompressor in mind, would complicate those compressors significantly (and create the need for a lot of state, too).  Not an improvement.

Grüße, Carsten

> On May 14, 2018, at 06:48, Hudson Randal Ayers <[email-masked]> wrote:
> 
> Hi all,
> 
> <design-considerations-low.pdf>_______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Hudson Randal Ayers <[email-masked]>
Date: Wed, 16 May 2018 05:15:10 +0000

Hi Carsten,

Thanks for taking a look, and for your response! Thought I would take a second to respond to a couple of your comments:

First, I agree that it is much easier to suggest a change in any Internet standard than it is to actually deploy such a change. Nevertheless, the first step in deploying any change is determining whether such a change would be beneficial if achieved, which is part of what we set out to do with this paper -- we found aspects of the protocol which we thought might be contributing to some of the existing interoperability problems, and sought to discuss these observations and to propose possible solutions. We of course do not mean to present the paper as the final word on the topic.

Second, one of the main conclusions in the paper actually goes against the idea that compressed mode should be mandatory. In fact, we posit that 6LoWPAN as a whole may be too focused on radio energy savings, at the expense of code size and complexity. We argue that there are applications for which reducing code size is more important than reducing the number of bits sent per-packet, and that devices in such applications would benefit from being able to simply communicate via uncompressed or barely compressed packets and not having to implement every aspect of 6LoWPAN described in RFCs 4944/6282/6775.

To explain our capability classes a little better - the existence of these classes actually does not require that a receiving node know what classes a sender supports, as the class of each received packet could be determined by simply observing the headers. To send to arbitrary nodes does, of course, require some state to determine if the receiving node supports a given compression class on reception. However, for the format we have suggested this would not require a significant amount of state - each node could store the capability class of any neighboring node using just 3 bits, and for most applications this is less than would likely be stored about such a neighbor to enable address compression etc. We are working on an implementation of these capability classes and have found that the state which must be stored is significantly less than the code space savings which this design enables for low-memory devices. Further, because the classes simply involve a division of "features" which 6LoWPAN already requires, little additional complexity is added to handle capability-class based compression. As a result, this scheme results in reduced code size and complexity for devices implementing the "lower" classes, at the expense of only slightly increased complexity for devices implementing the "top-level" class (analogous to supporting the full 6LoWPAN spec as it stands today).

Once again, thanks for your response, and for taking the time look at the paper. I hope this reply helps.

Best,

Hudson

________________________________
From: Carsten Bormann <[email-masked]>
Sent: Monday, May 14, 2018 11:22:46 PM
To: Hudson Randal Ayers
Cc: [email-masked]
Subject: Re: [6lo] Some observations and suggestions regarding 6LoWPAN interoperability

Hi Hudson,

interesting research!

Grüße, Carsten

> https://www.ietf.org/mailman/listinfo/6lo
6lo Info Page - Internet Engineering Task Force<https://www.ietf.org/mailman/listinfo/6lo>
www.ietf.org
6lo -- Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks. About 6lo

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 16 May 2018 07:46:08 +0200

On May 16, 2018, at 07:15, Hudson Randal Ayers <[email-masked]> wrote:
> 
>  6LoWPAN as a whole may be too focused on radio energy savings, at the expense of code size and complexity.

I would maintain that we hit exactly the sweet spot here, at least with respect to RFC 6282 (6LoWPAN header compression).

> We argue that there are applications for which reducing code size is more important than reducing the number of bits sent per-packet,

I would love to know more about these applications.  I would also like to discuss code sizes in a quantitative way — how big is a 6282 decompressor?  (You can already leave out most of the compressor.)

Maybe it is also worth discussing implementation strategies that don’t follow the (paper-only) model of “compression”, but instead operate on the 6282 representation right away.

> and that devices in such applications would benefit from being able to simply communicate via uncompressed or barely compressed packets and not having to implement every aspect of 6LoWPAN described in RFCs 4944/6282/6775. 

Let’s discuss 6282 separately from 4944 and 6775 — the latter just is going through an update that is intended to reduce some of the complexity (while introducing some other complications, unfortunately).  I don’t think there is much that can be reasonably shaved off 4944.  Neighbor discovery (6775) is a completely different beast, though, and a fresh look at this might bear the most bountiful fruit.

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 16 May 2018 12:29:48 +0000

Hello Hudson

Thanks a bunch for the effort and for sharing it, I'll need to find a window of time ASAP to review it all.

In the meantime, you may consider RFC 8138 and consider whether the 6LoRH operation for RPL data packets goes along with your desired philosophy.
The goals there were to 1) make the addition and removal of headers much simpler, 2) enable a minimal manipulation when forwarding and 3) always operate on the compressed form / never decompress when forwarding.

Cheers;
Pascal

From: 6lo <[email-masked]> On Behalf Of Hudson Randal Ayers
Sent: mercredi 16 mai 2018 07:15
To: Carsten Bormann <[email-masked]>
Cc: [email-masked]
Subject: Re: [6lo] Some observations and suggestions regarding 6LoWPAN interoperability

Hi Carsten,

Best,

Hudson

Hi Hudson,

interesting research!

I can't say I have processed all the details in the paper, but I would like to point to one need that we have in maintaining a protocol that has been around for a decade: It is not always useful to say "B would have been better than A" - we are much more interested in ways to get from a deployed A to a deployed B.  Sometimes that transition negates all of the positive effects that opting for B would have had in the first place; sometimes the transition is just hard to engineer so it stays beneficial.

One example of "B would have been better than A" is uncompressed mode.  6LoWPAN includes that packet format because it seemed simple.  Of course, compressed mode is also mandatory, and is what actually gets used (it is so much more efficient).  When we finally ran a formal interop in 2013, we were shocked to find out that more than half of the interop problems were with the "simple" uncompressed mode!  Having a rarely executed "simple" mode in addition to the one that gets tested and debugged was a big mistake.  This was corrected in the 6lo ports to other radios (by simply not including uncompressed mode), but is hard to fix for the original 6LoWPAN, where, as you note, some implementations gratuitously send uncompressed mode.

I'm not sure I understand your capability classes.  Today, an implementation does not have to know what the compressor of the peer actually supports - it just has to be able to decompress, which is a non-trivial, but limited amount of code.  Creating capability classes that restrict what the compressor is allowed to do with any specific decompressor in mind, would complicate those compressors significantly (and create the need for a lot of state, too).  Not an improvement.

Grüße, Carsten

---

From: Philip Levis <[email-masked]>
Date: Wed, 16 May 2018 07:53:51 -0700

Full disclosure: I’m a co-author on the paper.

> On May 15, 2018, at 10:46 PM, Carsten Bormann <[email-masked]> wrote:
> 

We went into the process of implementing 6lowpan on Tock with the same assumption. But after encountering some challenges in implementation, the students looked at other implementations for inspiration. They found pervasive interoperability problems seemingly driven by code complexity. So I guess I’m trying to reconcile the statement that 6282 is "exactly the sweet spot" with the results the paper reports on multiple open-source implementations. Could you explain your reasoning?

> I would love to know more about these applications.  I would also like to discuss code sizes in a quantitative way — how big is a 6282 decompressor?  (You can already leave out most of the compress…

Table 3 starts to answer this question, although it does not separate compression from decompression. In my experience, packet decompressors tend to be more complex than compressors (due to branches and edge cases).

> Maybe it is also worth discussing implementation strategies that don’t follow the (paper-only) model of “compression”, but instead operate on the 6282 representation right away.

Why? No implementation does this. It implies that every implementation always compresses maximally. As a result, such an implementation stops interoperating with partial implementations, i.e., every open-source implementation the paper examines. These aren't paper-only models of compression, but rather *what every open-source instance of working code does.*

I’d like to emphasize that the paper doesn’t suggest changing the 6lowpan compression specification/packet formats (well, except don’t ever elide UDP checksums). Instead, it suggests adding an ICMP error indicate that a packet was compressed in a way that the receiver cannot process, and defines how a sender can use that error to understand what a receiver can process. Please read the paper.

Phil

---

From: Hudson Randal Ayers <[email-masked]>
Date: Thu, 17 May 2018 06:46:09 +0000

> I would love to know more about these applications.

Section 3.2 notes the prevalence of compile-time options to reduce the size of various 6LoWPAN implementations, which implies that users required this functionality for various applications.

> I would also like to discuss code sizes in a quantitative way — how big is a 6282 decompressor?  (You can already leave out most of the compressor.)

While it is true that you can leave out most of the compressor if you want to do so, this does not actually result in huge savings, given that implementing the decompressor requires many of the same subroutines that the compressor requires. In table 3 of the paper of the paper we provide some code size measurements, which vary some between stacks. It is a difficult to isolate exactly how much code size can be attributed just to 6282, however, as most implementations intertwine fragmentation and compression to some extent, and as it is hard to estimate how much the code that calls fragmentation/compression functions is complicated by the existence of 6282. We discuss this in section 3.2.

> representation right away.

Hmm, I am not sure I understand what you mean by this. Could you explain? Are you suggesting a different capability spectrum than the one we lay out?

> Let’s discuss 6282 separately from 4944 and 6775 — the latter just is going through an update that is intended to reduce some of the complexity (while
> introducing some other complications, unfortunately).  I don’t think there is much that can be reasonably shaved off 4944.  Neighbor discovery (6775) is
> a completely different beast, though, and a fresh look at this might bear the most bountiful fruit.

We did find that 4944 is much smaller than the other two, but certain aspects of 4944 exist that are not implemented often, such as decompression of the broadcast header and the headers required for mesh-under support. Also, implementations of 4944 and 6282 are often closely intertwined, which can complicate analyzing them separately. I agree that discussing 6775 on its own would work well, and might be particularly interesting, though we do not analyze it as much in the paper because only two of the stacks we analyzed had full implementations.

---

From: Philip Levis <[email-masked]>
Date: Tue, 22 May 2018 11:10:58 -0700

Sorry, I forgot to mention that I had inline comments; they’re below — Carsten, what do you think?

Phil

> On May 16, 2018, at 7:53 AM, Philip Levis <[email-masked]> wrote:
> 
> _______________________________________________
> 6lo mailing list
> [email-masked]

---

From: Hudson Randal Ayers <[email-masked]>
Date: Wed, 23 May 2018 04:22:25 +0000

Hey Pascal,

Regarding RFC 8138:

I agree that the 6LoRH could help with some of the concerns mentioned in the paper, especially because it could serve as an alternative to additional ND options for transmitting information regarding what compression class is supported by a given node. The ability for forwarding nodes to forward packets despite not understanding all headers also aligns with the general philosophy we promote. However, I still think it is important that nodes have the option to reduce the amount of code dedicated to compression, mesh/broadcast headers, and RFC 6775 for applications in which that code takes up space that is required for the application itself, as we describe in the paper, so I would not consider the 6LoRH sufficient to address our concerns.

Either way, I would love to hear your thoughts on the paper once you get a chance to review it more thoroughly.

Best,

Hudson

________________________________
From: Pascal Thubert (pthubert) <[email-masked]>
Sent: Wednesday, May 16, 2018 5:29:48 AM
To: Hudson Randal Ayers; Carsten Bormann
Cc: [email-masked]
Subject: RE: [6lo] Some observations and suggestions regarding 6LoWPAN interoperability

Hello Hudson

Thanks a bunch for the effort and for sharing it, I’ll need to find a window of time ASAP to review it all.

Cheers;

Pascal

Hi Carsten,

Best,

Hudson

Hi Hudson,

interesting research!

Grüße, Carsten

www.ietf.org