Hi Julien: I suspect that the typical usage of IPv6 addresses in LoWPAN next year will not be that different from the typical usages of IPv6 addresses today; in particular the matching between source and destination scopes that the draft supports is very classical to what SAS does though some applications like ping will enable otherwise.
What is a lot less clear to me is the usage of other fields, RH, options headers, etc... Additional dispatch bits might become handy when we figure that out and I'd not lock too many of them if we can avoid that. Like I said we have a reference. If you show clear improvement for acceptable cost, then I'm sure the group will be interested. Let's see what the clear improvement comes first, and then we'll see if the cost is acceptable for that improvement. In particular, I'd wish to understand the benefits on the resulting implementation. Pascal >-----Original Message----- >From: Julien Abeille (jabeille) >Sent: lundi 13 octobre 2008 14:11 >To: Julien Abeille (jabeille); Pascal Thubert (pthubert); Jonathan Hui; Carsten Bormann; >[email protected]; Geoff Mulligan >Subject: RE: [6lowpan] rfc4944, hc and dispatchs > >Formatting problem, I resend: > >----Original Message----- >From: Pascal Thubert (pthubert) >Sent: lundi 13 octobre 2008 12:16 >To: Julien Abeille (jabeille); 'Jonathan Hui'; 'Carsten Bormann'; '[email protected]'; 'Geoff >Mulligan' >Subject: RE: [6lowpan] rfc4944, hc and dispatchs > > >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 > >[Julien] As I said in my previous email, with all this in mind, I am convinced we can afford 32 >values for HC (this is 13 bits, 5 in the dispatch, plus one byte) Do people agree that 32 values for >HC is ok? > >- will require a revamp of 4944 right away with no backward compatibility > >[Julien] sure, do the chairs or people think we must take this as design constraint? > >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 > >[Julien] I think that as long as we do not need another BYTE and respect the maximum limit we fix, >adding bits is at the contrary a very good point for simplicity and implementation size. > >- Compressing cases for which we have no known usage has very marginal value. > >[Julien] As we do not know what the typical usage will be in 12 month, I would avoid taking this as a >design constraint. Again, I propose to make the best use possible of the bits we have. If do not have >enough space to support some scenarios, then I am ok not to support them. > >Regards, >Julien > >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Julien Abeille >(jabeille) >Sent: lundi 13 octobre 2008 14:08 >To: Pascal Thubert (pthubert); Jonathan Hui; Carsten Bormann; [email protected]; Geoff Mulligan >Subject: Re: [6lowpan] rfc4944, hc and dispatchs > >Hi Pascal, all, > >I comment inline > >-----Original Message----- >From: Pascal Thubert (pthubert) >Sent: lundi 13 octobre 2008 12:16 >To: Julien Abeille (jabeille); 'Jonathan Hui'; 'Carsten Bormann'; '[email protected]'; 'Geoff >Mulligan' >Subject: RE: [6lowpan] rfc4944, hc and dispatchs > >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 [Julien] As I said in my previous email, with all >this in mind, I am convinced we can afford 32 values for HC (this is 13 bits, 5 in the dispatch, plus >one byte) Do people agree that 32 values for HC is ok? >- will require a revamp of 4944 right away with no backward compatibility [Julien] sure, do the >chairs or people think we must take this as design constraint? > >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 [Julien] I think that as long as we do not >need another BYTE and respect the maximum limit we fix, adding bits is at the contrary a very good >point for simplicity and implementation size. >- Compressing cases for which we have no known usage has very marginal value. >[Julien] As we do not know what the typical usage will be in 12 month, I would avoid taking this as a >design constraint. Again, I propose to make the best use possible of the bits we have. If do not have >enough space to support some scenarios, then I am ok not to support them. > >Regards, >Julien > > >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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
