On May 16, 2018, at 07:15, Hudson Randal Ayers <[email protected]> wrote: > > 6LoWPAN as a whole may be too focused on radio energy savings, at the > expense of code size and complexity.
I would maintain that we hit exactly the sweet spot here, at least with respect to RFC 6282 (6LoWPAN header compression). > We argue that there are applications for which reducing code size is more > important than reducing the number of bits sent per-packet, I would love to know more about these applications. I would also like to discuss code sizes in a quantitative way — how big is a 6282 decompressor? (You can already leave out most of the compressor.) Maybe it is also worth discussing implementation strategies that don’t follow the (paper-only) model of “compression”, but instead operate on the 6282 representation right away. > 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. Let’s discuss 6282 separately from 4944 and 6775 — the latter just is going through an update that is intended to reduce some of the complexity (while introducing some other complications, unfortunately). I don’t think there is much that can be reasonably shaved off 4944. Neighbor discovery (6775) is a completely different beast, though, and a fresh look at this might bear the most bountiful fruit. Grüße, Carsten _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
