Hi Pascal, I've asked for a time slot to talk about HCx and will incorporate stuff we've been discussing so far. We can bring up the discussion of further compressing the HC's there as well.
-- Jonathan Hui Pascal Thubert (pthubert) wrote: > 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
