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 protected]> wrote: > > 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 > <design-considerations-low.pdf>_______________________________________________ > 6lo mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lo _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
