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

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Aug 2018 18:38:19 -0400

Thank you for this great work, and I'm glad that there was just enough
time as the end of 6lo to present it.

While I think that in the short term we will get interoperability only
because there are various industrial alliances that will define profiles,
in the long term, we need to overcome the problems outlined in this document.

There is a space beyond the industrial alliances: to the places the people
who write the various #ifdef to turn various things on and off, would like to
be able to do a better job.  Both because of just quality of implementation,
but also because of just trying to debug stuff.

And the industrial alliances still need some meat on which base their
deliberations!

We need that ICMP message.

I'm not sure what to do with the survey.
It's a lot of really good work, and it deserves recognition.
I suggest that maybe it should be published in a journal rather than as an
RFC.  Maybe the https://www.ietfjournal.org/ would be a good place.

As for the document.  I want to suggest that the WG adopt it.
I haven't read it in detail, but I can do that.  I prefer to adopt it
in order so that we can spend top-of-the-agenda time to figure out what
to do with the document.  I suspect that a bunch of it will get removed,
and that the document will change name, but I think we can do that.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 2 Aug 2018 08:01:11 +0200

> 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.

Grüße, Carsten

---

From: Philip Levis <[email-masked]>
Date: Wed, 1 Aug 2018 23:27:54 -0700

Riot, Nest’s OpenThread and ARM’s mbed are not research activities.

Phil

> On Aug 1, 2018, at 11:01 PM, Carsten Bormann <[email-masked]> wrote:
> 
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Aug 2018 11:17:51 -0400

> 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.

Some argue that IPv4 was the research version of the Internet.

That's why we should adopt the document, so that we can discuss things like
whether we need more variants...

    > Adding more
    > variants of 6LoWPAN to the mix is NOT going to help with that.

or probably *FEWER* variants.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Philip Levis <[email-masked]>
Date: Fri, 3 Aug 2018 14:52:54 -0700

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.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 4 Aug 2018 06:56:10 +0200

Hi Philip,

I think we have strong agreement that code space is at a premium.  (There are lots of people who’d rather sell bigger micros than enable the smaller ones, but the point of the whole constrained node network activity is to expand the Internet to less capable platforms.)

There are also limits in what realistically can be achieved; a proper citizen of the Internet does need security, so some minimum capability will be required.  Hence RFC 7228.

Now how do we get there?  When implementing protocols, my experience is that the most expensive “feature” is *having* “features”, i.e., options that can be switched on and off.  **It generally costs about the same to handle optionality as it costs to make something mandatory**.  That’s why so many things are mandatory in 6LoWPAN — it is much easier to communicate if you can simply rely on a common standard.  (We made some mistakes here, such as leaving in the choice to send uncompressed — fixed in later 6lo protocols.  We also can argue whether RFC 6282 actually hits the sweet spot between complexity and efficiency.  But the decision not to break it up into a zillion of features [except for something relatively expensive such as RFC 7400] was right.)

Why didn’t the ecosystems generate pressure to actually implement the standard?  We seem to have different perceptions.  I stand by my observation that interoperability (except with themselves) wasn’t really an objective in many of the efforts.   So parts are left unimplemented.  As a WG, 6LoWPAN did little to initiate remedies; e.g., we only ever had one interop event (Berlin 2013).  You might say failing to promote interoperability some more was a failure of the chairs, and I couldn’t really disagree.  But the ecosystem that was breathing “optimize for grant proposal” instead of “optimize for interoperability” was its own challenge, too.

Now how do we solve this?  Adding fine-grain optionality to all corners of the protocol is not helping.  I think this is where we have very different perception, and I would like to find out why you think it does.

I agree that improving diagnostic capabilities would also be useful, so you can find out what is broken.  But we disagree on who should bear the burden of dealing with brokenness: I don’t agree that complicating everything else to deal with a broken implementation is the right approach.  Keep things simple and fix the brokenness!

Grüße, Carsten

---

From: Hudson Randal Ayers <[email-masked]>
Date: Sat, 4 Aug 2018 21:49:07 +0000

Hi Carsten,

I am happy to hear we are in agreement that code space is at a premium.

We are also in agreement that it is much easier to communicate if you can simply rely on a common standard -- however, I think that one of the key observations that I presented at IETF 102 is that the current state of the 6LoWPAN RFCs have not led to a common standard, and that while you claim to have chosen "not to break it up into a zillion features", the implementers of 6LoWPAN have effectively done so for you, by leaving out "MUST" requirements of the specification seemingly at random.

I would argue that someone planning to implement 6LoWPAN today might look at existing implementations and decide that fine-grain optionality is exactly what exists today, regardless of the language included in the various RFCs. The reason for proposing the interoperability classes included in draft-ayers-low-power-interop is precisely to produce coarser-grained optionality, such that if implementers do opt out of some of the many various "must" requirements in 6LoWPAN - as almost all implementations already seem to do - they at least do so in a manner defined by the spec, and do so in a manner that can be easily communicated.

This brings us to your point that making options switchable is often more expensive than simply making all of those options required. However, I believe that the options, as presented in the draft, do  a good job of passing this cost up to the more resourceful devices, while still allowing very constrained nodes to implement the simplest classes without requiring that these nodes have any knowledge regarding what higher-level classes exist. Any device that receives a 6LoWPAN messgage which it cannot successfully parse simply responds with a single ICMP message. I find it hard to beleive this would add substantial code size to any implementation. The more resourceful device would be presented with the added cost of parsing this ICMP message, and reducing the amount of compression used to resend accordingly -- but this design which puts the cost on devices already known to have more code space available (as these are the devices which could afford to implement every "MUST" requirement in each RFC) seems to me a sensible design.

Finally, even if you are completely in disagreement with regards to the idea of having capability classes, I still fail to understand why you do not support adding an ICMP message which any 6LoWPAN node can respond with when it fails to parse a 6LoWPAN-compressed message. The code-space cost to handle sending a single such message in response to decompression failures is tiny -- almost certainly less than a few hundred bytes of ROM -- and would substantially improve diagnostics and error-handling when determining failures in interoperating 6LoWPAN networks. The idea that deterministic, silent interoperability failures are a totally acceptable reality in these networks is extremely surprising to me, especially given that such an obvious and inexpensive solution seems to exist.

Best,

Hudson Ayers

________________________________
From: 6lo <[email-masked]> on behalf of Carsten Bormann <[email-masked]>
Sent: Friday, August 3, 2018 9:56:10 PM
To: Philip Levis
Cc: Michael Richardson; [email-masked]
Subject: Re: [6lo] adoption of draft-ayers-low-power-interop-00, and industrial specifications

Hi Philip,

Grüße, Carsten