Hi Pascal, Given that it looks like we can include two of your three proposals into HC1g, I'm not so sure whether defining a new format adds that much benefit. Adding the ability to elide the UDP checksum and the hop limit into HC1g already provides 3 bytes of savings. Compared to your proposed modifications to HC1g, HC3 only saves one byte (which you've observed). I'll put this idea out now, but I believe HC1g has the potential to supersede HC1+HC2. Really, we should rename HC1g to be something like HCx since it's not really specific to routable addresses.
My alternative proposal is as follows: - Use the HCx format for both link-local and non-link-local communication. - Define a dispatch HCl when communicating with link-local addresses. - Define a dispatch HCr when communicating with routable addresses. The reason why I'm pushing for a single format is that I believe the most optimized code will work with the format directly to save RAM and code. That means that 6LoWPAN nodes generally do not expand compressed datagrams into uncompressed datagrams and the other way around. Thus, it involves more than just the encoder/decoder functions and could involve the entire stack (including the application). What do you/others think? -- Jonathan Hui Pascal Thubert (pthubert) wrote: > Hi Jonathan and all: > > I'd wish to move forward on the original subject for this thread. > > Basically the question is whether it is worth consuming a dispatch for > an HC3 that would represent the best case of what HC1 and HC2 can > compress. > > Pros: saves one byte in the headers and a fast path in the code > Cons: Additional encoding complexity and one dispatch. > > On the side, there's a compression mechanism coming up for ULA/GLO > (HC1g). > Can we make HC3 ready for that upcoming mechanism? Should we wait? > > I'll ask Geoff if some discussion can happen in Philly to conclude on > the topic. > > Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
