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 protected]> Sent: Monday, May 14, 2018 11:22:46 PM To: Hudson Randal Ayers Cc: [email protected] Subject: Re: [6lo] Some observations and suggestions regarding 6LoWPAN interoperability 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 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
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
