Full disclosure: I’m a co-author on the paper. > On May 15, 2018, at 10:46 PM, Carsten Bormann <[email protected]> wrote: > > 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 went into the process of implementing 6lowpan on Tock with the same assumption. But after encountering some challenges in implementation, the students looked at other implementations for inspiration. They found pervasive interoperability problems seemingly driven by code complexity. So I guess I’m trying to reconcile the statement that 6282 is "exactly the sweet spot" with the results the paper reports on multiple open-source implementations. Could you explain your reasoning? > >> 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.) Table 3 starts to answer this question, although it does not separate compression from decompression. In my experience, packet decompressors tend to be more complex than compressors (due to branches and edge cases). > 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. Why? No implementation does this. It implies that every implementation always compresses maximally. As a result, such an implementation stops interoperating with partial implementations, i.e., every open-source implementation the paper examines. These aren't paper-only models of compression, but rather *what every open-source instance of working code does.* I’d like to emphasize that the paper doesn’t suggest changing the 6lowpan compression specification/packet formats (well, except don’t ever elide UDP checksums). Instead, it suggests adding an ICMP error indicate that a packet was compressed in a way that the receiver cannot process, and defines how a sender can use that error to understand what a receiver can process. Please read the paper. Phil _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
