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 protected]> on behalf of Carsten Bormann <[email protected]> Sent: Friday, August 3, 2018 9:56:10 PM To: Philip Levis Cc: Michael Richardson; [email protected] Subject: Re: [6lo] adoption of draft-ayers-low-power-interop-00, and industrial specifications 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 _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
