> I would love to know more about these applications.
Section 3.2 notes the prevalence of compile-time options to reduce the size of various 6LoWPAN implementations, which implies that users required this functionality for various 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..) While it is true that you can leave out most of the compressor if you want to do so, this does not actually result in huge savings, given that implementing the decompressor requires many of the same subroutines that the compressor requires. In table 3 of the paper of the paper we provide some code size measurements, which vary some between stacks. It is a difficult to isolate exactly how much code size can be attributed just to 6282, however, as most implementations intertwine fragmentation and compression to some extent, and as it is hard to estimate how much the code that calls fragmentation/compression functions is complicated by the existence of 6282. We discuss this in section 3.2. > 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. Hmm, I am not sure I understand what you mean by this. Could you explain? Are you suggesting a different capability spectrum than the one we lay out? > 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. We did find that 4944 is much smaller than the other two, but certain aspects of 4944 exist that are not implemented often, such as decompression of the broadcast header and the headers required for mesh-under support. Also, implementations of 4944 and 6282 are often closely intertwined, which can complicate analyzing them separately. I agree that discussing 6775 on its own would work well, and might be particularly interesting, though we do not analyze it as much in the paper because only two of the stacks we analyzed had full implementations.
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
