Hi Zach: The 2 bits were integrated in HC when we passed the HC to 2 bytes (that was hc_00). With hc_01, we are back to one byte and not too ready to bounce again. I mean, there are many things we could do with more bits in HC but then we're loosing the value of compression in the first place.
Since most times the default context is the right one, we decided to handle the exception by putting the context information in an optional byte that should "almost" never by there if the context is used for renumbering only. At that point we have that additional byte, we can shoot for 16 contexts both directions. This might not be the best use of that byte, and we should discuss that furthermore. But a context might not be limited to a prefix. We can use a context to (state)fully compress an address like the address of an edge router. One byte against 8 or 16 per packet might be worth an entry in memory. Now you made it very clear that not all nodes can support 16 many contexts. Fine. We need to work on how the option is really optional, and how a node may not have to support all contexts. OTOH, the consensus on 2 contexts had to do with the cost in bits in every packet. Now we moved to a cost that is only paid by exceptional packets, 16 MAX might become a good value after all. I think that all this requires more thoughts. Once we really understand what we do with contexts and what the cost is per type of context entry, then we can figure out what the right value is, and whether all entries are globally significant or not. What do you think? Pascal >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zach Shelby >Sent: lundi 13 octobre 2008 11:14 >To: Julien Abeille (jabeille) >Cc: 6lowpan >Subject: Re: [6lowpan] Fwd: New Version Notificationfordraft-ietf-6lowpan-hc-01 > >Hi, > >I don't think the consensus changed from that 2 contexts is enough.. it >was just mentioned that with more someone may figure out what to do with >them (renumbering). If renumbering is the only case for having a 4-bit >context identifier, then I recommend Jonathan tries to integrate a short >1-2 bit context identifier into the base format as he mentioned is >possible, thus avoiding the 1 byte extension for 4-bit identifiers. 2-4 >contexts will be plenty, and thus we wouldn't be using memory on all >nodes, or having to deal with some nodes supporting 16 and some >supporting 2. Considering that we have only a link-local context in >RFC4944, having 2-4 global contexts is already a huge improvement! > >So I would give like to see 1-2 context ID bits for source/dest in the >base header, as a priority over supporting a large range of multicast >address types. > >- Zach > >Julien Abeille (jabeille) wrote: >> Hi Zach, >> >> I second your concern >> >> There was recently a discussion specifically about the number of >> contexts needed. >> There seemed to be a consensus that multiple contexts was useful for >> renumbering only, which is rare, and that 2 contexts was enough. >> Was there new input since then which justifies the use of 4-bit >> contexts? >> >> Cheers, >> Julien >> >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of Zach Shelby >> Sent: vendredi 10 octobre 2008 14:58 >> To: Jonathan Hui >> Cc: 6lowpan >> Subject: Re: [6lowpan] Fwd: New Version Notification >> fordraft-ietf-6lowpan-hc-01 >> >> Hi, >> >> Here are my comments on hc-01. Overall I think we are quite close with >> the comments from Pascal and Julien. >> >> I found the DDF name confusing. Now it has been renamed CTX in the >> latest formats on the list, great. >> >> As Pascal pointed out, nodes need to be able to decode all these >> options. One thing that worries me in having 16 contexts, is that nodes >> are forced to store them all. That is worst case 272 bytes of memory >> consumption. Worth it? Is it possible that an ultra-simple node would >> only have to understand the default context? >> >> The default context identifier '0000' could be clarified more in the >> draft. When CTX is '10' then the default context identifier '0000' is >> used. It should be made clear that this is the prefix advertised in RAs >> as useable for SAA. >> >> Regarding the ND for 6lowpan draft, HC-01 means we need to add a 4-bit >> context identifier flag to the 6LoWPAN Prefix Information Option. To >> make things clear that should always be '0000' if the A flag is '1'? >> >> - Zach >> >> >> Jonathan Hui wrote: >>> http://tools.ietf.org/html/draft-ietf-6lowpan-hc >>> >>> This new version reflects the recent discussions on the list. The >>> changes are: >>> - HC back to 1 byte by default by stealing a few bits from the >>> dispatch field. >>> - Added better support for multicast address compression. >>> - Fixed alignment for UDP port compression. >>> - Better support for Traffic Class and Flow Label compression. >>> - Pascal joined as an author. >>> >>> Happy reading! >>> >>> -- >>> Jonathan Hui >>> >>> >>> >>> Begin forwarded message: >>> >>>> From: IETF I-D Submission Tool <[EMAIL PROTECTED]> >>>> Date: October 8, 2008 7:15:35 PM PDT >>>> To: [EMAIL PROTECTED] >>>> Cc: [EMAIL PROTECTED] >>>> Subject: New Version Notification for draft-ietf-6lowpan-hc-01 >>>> >>>> >>>> A new version of I-D, draft-ietf-6lowpan-hc-01.txt has been >>>> successfuly submitted by Jonathan Hui and posted to the IETF >> repository. >>>> Filename: draft-ietf-6lowpan-hc >>>> Revision: 01 >>>> Title: Compression Format for IPv6 Datagrams in 6LoWPAN >> Networks >>>> Creation_date: 2008-10-09 >>>> WG ID: 6lowpan >>>> Number_of_pages: 15 >>>> >>>> Abstract: >>>> This document specifies an IPv6 header compression format for IPv6 >>>> packet delivery in 6LoWPAN networks. The compression format relies >>>> on shared context to allow compression of arbitrary prefixes. This >>>> document specifies compression of multicast addresses and a framework >> >>>> for compressing next headers. This framework specifies UDP >>>> compression and is prepared for additional transports. >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>> _______________________________________________ >>> 6lowpan mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/6lowpan >> > >-- > >Zach Shelby >Head of Research >Sensinode Ltd. >Kidekuja 2 >88610 Vuokatti >FINLAND > >mobile: +358 40 7796297 > >This e-mail and all attached material are confidential and may contain >legally privileged information. If you are not the intended recipient, >please contact the sender and delete the e-mail from your system without >producing, distributing or retaining copies thereof. >_______________________________________________ >6lowpan mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
