Hi Jonathan: I'm can't wait to see the proposal that saves the 3 additional bytes as we discussed turn into a WG doc, and that would be the priority. I'm also concerned that the 3 bytes be elided when the addresses are link local because that's the current use in ISA100, though I'm pretty sure we could use HC1G there.
I think that the work on compressing the HCs themselves is also important because each byte in the headers is a percentage of battery-life (or something). And that's mostly orthogonal work. They intersect if: - we need to delay HC3 till HC1's are well defined - We're missing dispatch bits. So I still wish to have the question discussed in Philly if that's possible within constraints... Pascal >-----Original Message----- >From: Jonathan Hui [mailto:[EMAIL PROTECTED] >Sent: jeudi 6 mars 2008 17:29 >To: Pascal Thubert (pthubert) >Cc: 6lowpan >Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 > > >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
