Hi Julien: Pseudo code is good. Please remember that the reference is the current spec, so we need to compare pseudo code of a proposed change with pseudo code of that reference. In the reference, the compression of the pair of addresses is specifiied using 6 bits.
Consuming more and more of the dispatch space: - multiplies by 2 the number of consumed dispatches each time - reduces the space allocated for future extensions - will require a revamp of 4944 right away with no backward compatibility It's very hard to reach a solution than will please all for all the various standpoints and priorities (smaller HC, lmarger coverage, smaller code, smaller memory...). And we could keep changing these formats forever. So we need rules and limits, in particular we need to keep in mind that: - Making implementation simpler or smaller is good - Making the base HC bigger is bad, every bit costs dearly - Compressing cases for which we have no known usage has very marginal value. Would you agree with that? Pascal >-----Original Message----- >From: Julien Abeille (jabeille) >Sent: lundi 13 octobre 2008 10:14 >To: Jonathan Hui; Pascal Thubert (pthubert); Carsten Bormann; [email protected]; Geoff Mulligan >Subject: RE: [6lowpan] rfc4944, hc and dispatchs > >Hi Jonathan , all, > >I do not have particular use cases in mind for specific address types. > >My approach is the following: >- how many bits can we afford? >- with this amount of bits, let's try to support as many IP scenarios as possible, keeping a low >level of complexity and a high level of clarity. > >For the first question: >- there are currently around 150/255 dispatch values used. >- A priori I would be in favor of deprecating some (mesh, not a lowpan frame), or at least do you >agree they are less important than HC. This would drag the number of values to 25/255 >- I do foresee some new 6lowpan specs will take some of them, but not that many. Do you see anything >else appart from fragment recovery? >Hence I am convinced taking 32 values is very acceptable (this is 8 bits for address compression) >Do you agree with this? > >For the second question: >- with 8 bits for address compression, we can do something very clean and easy to implement, handling >all IP addressing scenarios. > >I will send today an example on 8bits and pseudo code to be able to compare 7-bit/8-bit complexity > >Regards, >Julien > > > >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Hui >Sent: vendredi 10 octobre 2008 19:09 >To: Pascal Thubert (pthubert) >Cc: Carsten Bormann; [email protected]; Geoff Mulligan >Subject: Re: [6lowpan] rfc4944, hc and dispatchs > > >Hi Pascal, > >Yes, you are right - hc-01 supports all header values (just carry everything in-line). > >Regarding Julien's comments, I think hc-01 and the format proposed to support Julien's cases are >straight-forward to implement. I think the more important issue is whether Julien's cases will be >common in 6LoWPAN applications. We (Arch Rock) do not commonly use the cases that Julien wishes to >add compression for. But if Julien/others can demonstrate a strong need for them (i.e. cases that >will be used fairly often in relevant 6LoWPAN applications), then I do think we should consider them. >Julien, can you explain important commonly used cases that would not be supported by hc-01? > >-- >Jonathan Hui > > > >On Oct 10, 2008, at 9:41 AM, Pascal Thubert (pthubert) wrote: > >> Hi Jonathan >> >> Maybe a good reason to stick to the current format and change the >> misleading wording around it, what do you think? In any case, I'm all >> for starting 4944bis and recoverable frags today, though. >> >> Pascal >> >>> -----Original Message----- >>> From: Jonathan Hui [mailto:[EMAIL PROTECTED] >>> Sent: vendredi 10 octobre 2008 18:02 >>> To: Pascal Thubert (pthubert) >>> Cc: Carsten Bormann; Geoff Mulligan; [email protected] >>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>> >>> >>> Hi Pascal: >>> >>> I'm for pushing HC through as quickly as possible. We are already >>> behind according to the charter text. >>> >>> The one dependency I see is the structure of the dispatch byte. If we >>> choose a dispatch value(s) that is compatible with RFC 4944, then we >>> are fine, I think. But if we want extra bits by changing the layout >>> of the dispatch values/identifiers for Frag/Mesh headers (as both I >>> and Julien have proposed) then this creates a dependency on defining >>> that new dispatch assignment scheme. >>> >>> -- >>> Jonathan Hui >>> >>> >>> On Oct 10, 2008, at 8:51 AM, Pascal Thubert (pthubert) wrote: >>> >>>> I'm all with you, Jonathan, as long as that does not delay HC. >>>> >>>> This is why I proposed a structured set of document that leaves HC >>>> with its current scope as opposed to making it a full revision of >>>> 4944. >>>> Makes >>>> sense? >>>> >>>> Pascal >>>> >>>>> -----Original Message----- >>>>> From: Jonathan Hui [mailto:[EMAIL PROTECTED] >>>>> Sent: jeudi 9 octobre 2008 21:17 >>>>> To: Pascal Thubert (pthubert) >>>>> Cc: Carsten Bormann; Geoff Mulligan; [email protected] >>>>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>>>> >>>>> >>>>> In general, I'm in support of Pascal's proposal. Cleaning up the >>>>> format to use a stacked-header format was just one of the items and >>>>> there were many other things we wanted to fix before pushing out >>>>> RFC 4944. But we were far too late to the game in doing a complete >>>>> overhaul of the doc. I think *now* is the time to make improvements >>>>> to RFC 4944. >>>>> >>>>> -- >>>>> Jonathan Hui >>>>> >>>>> >>>>> >>>>> On Oct 9, 2008, at 10:41 AM, Pascal Thubert (pthubert) wrote: >>>>> >>>>>> Hi Carsten: >>>>>> >>>>>> Some implementations and dependant standards would require a >>>>>> timeline for this. Leaving it up in the air does not help our >>>>>> users do their product planning? >>>>>> >>>>>> Considering the attention and the work on the new LOWPAN_IPHC, I >>>>>> expect that we'll be ready for WGLC after 2/3 more respins. That >>>>>> could be achieved by Minneapolis time if we can rally all >>>>>> interested parties >>>> to >>>>>> comment on the existing published spec. So could you chairs >>>>>> please: >>>>>> >>>>>>>>>>>>>>>> propose a time line to the WG along those lines >>>> <<<<<<<<<<<< >>>>>>>>>>>>>>>> raise WG attention on this work? >>>> <<<<<<<<<<<< >>>>>> >>>>>> Also by or at Minneapolis, my sensation is that we should not only >>>>>> discuss the terms of deprecating RFC 4944 HC but also consider the >>>>>> spec as a whole: >>>>>> >>>>>> - Mesh Header is a layer violation. I talked to implementers and >>>> their >>>>>> message is that they do not use it because it's never exactely >>>>>> what that specific radio needs; so they end up with their own mesh >>>>>> header >>>> anyway >>>>>> and will not duplicate things for the sake of comliance. Instead >>>>>> we might need a Routing header, pretty useful for source routing >>>>>> in >>>> route >>>>>> over. >>>>>> >>>>>> - Fragments are not recovered individually. We have enough >>>>>> experience to know where that leads should a 6LoWPAN network >>>>>> experience either high load or high BER. We have a draft on the >>>>>> works to deprecate that with recoverable fragments. >>>>>> >>>>>> - The Current HC WG doc covers all the compression cases in RFC >>>>>> 4944, bigger and badder. >>>>>> >>>>>> So what's left? >>>>>> >>>>>> My proposal is to start a 4944bis that would focus on the >> addressing >>>>>> architecture, would be the placeholder to control the dispatch >>>>>> type but would defer to the drafts/RFCs that actually detail the >>>>>> operation >> of >>>>>> each dispatch type. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Pascal >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> On >>>>>> Behalf Of Carsten Bormann >>>>>>> Sent: jeudi 9 octobre 2008 16:43 >>>>>>> To: Julien Abeille (jabeille) >>>>>>> Cc: Carsten Bormann; [email protected] >>>>>>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>>>>>> >>>>>>> On Oct 09 2008, at 16:09, Julien Abeille (jabeille) wrote: >>>>>>> >>>>>>>> - does it officialy deprecate the old header compression scheme? >>>>>>> >>>>>>> My impression of the mailing list consensus is that this is what >>>>>>> the WG wants to achieve. >>>>>>> At the time this was discussed, I cautioned that it is premature >> to >>>>>>> decide on replacing something existing with known flaws with >>>>>>> something not yet quite cooked (and, hence, with unknown flaws). >>>>>>> So I expect we'll ultimately decide this question at the time HC >>>>>>> and the related specs come up for WGLC. >>>>>>> Clearly, the stated intention of many WG members is to make this >>>>>>> happen, as it would be wasteful to support two HC schemes in tiny >>>>>>> implementations. >>>>>>> >>>>>>> Gruesse, Carsten >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 6lowpan mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>> _______________________________________________ >>>>>> 6lowpan mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >> > >_______________________________________________ >6lowpan mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
