Re: [6lo] adoption of draft-ayers-low-power-interop-00, and industrial specifications

[Philip Levis <[e-mail]>]

On Aug 1, 2018, at 11:01 PM, Carsten Bormann <[e-mail]> wrote:

On Aug 2, 2018, at 00:38, Michael Richardson <[e-mail]> wrote:

As for the document.  I want to suggest that the WG adopt it.

Hmm.  While the document has some interesting observations, I don’t think we should adopt any one of its conclusions.  The interop problems we are seeing in the research implementations are mostly coming from the fact that interop simply was not an objective in many of the research activities that led to those implementations.  Adding more variants of 6LoWPAN to the mix is NOT going to help with that.

Carsten,

I’m trying to understand your expectation for the convergence point of 6lowpan implementations, or why an ICMP error would not be helpful. I can imagine three possible end points — does one of these hit the mark, or is it something else?

Completion: Every 6lowpan implementation will support every feature of 6lowpan, and they will fully interoperate.

Silos: Some 6lowpan implementations in vertical application/network silos controlled by a single vendor will pick and choose the features they want, because they do not have to operate with other implementations. “Open” 6lowpan implementations will support every feature of 6lowpan.

Quilt (what we have today): Different implementations and builds of those implementations will pick and choose different sub-parts of the specification, and will deterministically fail to exchange certain packets. This is OK.

To me, none of these three endpoints is desirable.

*Completion* ignores the reality of implementations and the cost-benefit tradeoffs of embedded platforms. We can see, experimentally, that many years after the relevant RFCs, neither industrial nor research platforms implement the entire specification. These not-overlapping subsets cause devices to not interoperate in some cases. Code space is at a premium. One could argue that 6lowpan is only intended for bigger microcontrollers, because eventually all of them will have enough code memory, but I think this simultaneously excludes huge applications areas from being connected to the Internet and ignores what the price/resources tradeoffs are like in embedded systems.

*Silos* ignores the points above for open implementations that don’t belong in a silo. While it’s clear that we want 6lowpan to be able to support these silos (and allow their vendors/specification bodies to only use subsets of the features), making it harder for open systems to interoperate for the benefit of closed ones seems against some of the core tenets of the IETF. Furthermore, this puts open implementations in a weird and uncompetitive spot: they have to do more than siloed ones. Take, for example, the case of UDP checksum elision, which Pascal brought up at 102. His argument was that a vendor said that they would not use 6lowpan if they could not elide the checksum. I can explain why this fundamentally breaks the end-to-end argument (the original Saltzer and Reed, not RFC1958), but that doesn’t matter[1]. The issue is that, in 6lowpan, this feature is not an option or a MAY, it’s a MUST.

*Quilt* is problematic in that it eschews responsibility for encouraging and promoting interoperability. If the IETF doesn’t help define what it means to have “working code”, then other groups will. In the case of silos, this makes sense. But in the case of an open, interoperability Internet of Things, I’d expect the IETF wants to be the organization that guides and leads the effort.

Instead, it seems like the correct endpoint is one in which implementations (as they all do so today) can implement a subset of 6lowpan, but also detect when they use a feature that another device does not support. A device transmitting an unsupported packet does not have to do something in response (it could just not interoperate), but it can do something and try to interoperate.

Furthermore,  having an ICMP error doesn’t create a new implementation that will make existing devices not interoperate. It’s something which devices that do want to interoperate can use to do so more easily.

Phil

[1] Suppose there is a bug in your networking stack such that, when routing a packet, sometimes the UDP port is incorrectly stored in host order rather than network order. A link layer frame is received and passes link-layer integrity. The 6lowpan and UDP headers are inspected, and the packet is scheduled to be forwarded. At this point the UDP port is corrupted. This corrupted packet is then passed to the link layer, at which point the MAC covers the corrupted port.