Sorry, I forgot to mention that I had inline comments; they’re below — Carsten, what do you think?
Phil > On May 16, 2018, at 7:53 AM, Philip Levis <[email protected]> wrote: > > 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 _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
