I also agree. Now is the right time before we have to carry this design
baggage forward.
As Pascal pointed out - we then need to get HC done sooner.
geoff
On Thu, 2008-07-17 at 10:56 +0200, Anthony Schoofs wrote:
> I am also in favor of that approach.
> We have had issues with routing packets from 6lowpan nodes to IP
> hosts, and we definitively need the HC compression to make things
> cleaner and optimized.
>
> Anthony
> --
> Anthony Schoofs
> Research Scientist
> Philips Research
> High Tech Campus 34 , 5656 AE Eindhoven, The Netherlands
> Email: [EMAIL PROTECTED]
>
> Inactive hide details for Pascal"Pascal Thubert (pthubert)"
> <[EMAIL PROTECTED]>
>
>
> "Pascal Thubert (pthubert)"
> <[EMAIL PROTECTED]>
>
> Sent by:
> [EMAIL PROTECTED]
>
> 17-07-2008 10:13
>
>
> To
>
> "David Culler"
> <[EMAIL PROTECTED]>
> <[email protected]>
>
> cc
>
>
>
> Subject
>
> Re: [6lowpan] HC
>
> Classification
>
>
>
>
>
> Hi David:
>
> I do support that approach. I’d note that it would impose some
> pressure to release HC rather quickly.
> Is there a way to get a feedback on existing deployments that use
> 6LoWPAN HC1?
>
> Pascal
>
>
> ______________________________________________________________________
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of David Culler
> Sent: mercredi 16 juillet 2008 18:25
> To: [email protected]
> Subject: [6lowpan] HC
>
> It appears that the 6LoWPAN WG is poised to take up serious discussion
> of HC (http://www3.tools.ietf.org/html/draft-hui-6lowpan-hc-00) and I
> would like to encourage us to make a bold move forward while the
> number of "dusty deck 6LoWPAN implementations" are few - eliminate
> HC1/HC2 in the process.
>
> As a bit of background, the original format document defined HC1 for
> compression of link local IPv6 addresses and HC2 for compression of
> UDP and ICMP headers. Both were part of a rather awkward encoding.
> Most other parts of the encoding got cleaned up with the switch to the
> stacked header format that went to RFC. Aside from its awkwardness,
> HC1 was never sufficient, because it provided no compression of
> routable addresses, nor for the most useful multicast addresses - both
> rather essential to IPv6. HC1g was proposed to provide a similar
> (somewhat more effective) stateless compression of common addresses of
> global scope. This meant two similar compression schemes, HC1 for
> link-local, HC1G for global. Both are implementable with much less
> than a thousand lines of code. No ambiguity about when to use which.
>
> HC provides a much cleaner approach which subsumes both HC1 and HC1g,
> better supports multicast, and is much more usable with IPv6 stacked
> headers because the order of the subheaders is respected. (HC2 comes
> in between the dispatch and the address subheader, rather than as a
> portion of the transport subheader).
>
> The decision to take on HC, clean up the rough edges, and build
> consensus around it is the easy part. The bolder step that I would
> like to suggest is that we deprecate HC1 and get it removed soon.
>
> It is always easier to maintain backward compatibility than to make a
> clean break. But, ultimately that is burdening all the many future
> implementations in order to avoid a burden on the few current
> implementations.
>
> The reason to avoid this burden is not that either is a huge amount of
> code. Implementing any of these HCs is only several hundred LOC. The
> issue is testing and interoperability. The interoperability draft
> sheds some light on this. There are so many different compression
> forms and since each is an optimization on the uncompressed version,
> there are many different ways to represent the same thing. All with
> different sizes and offsets. At least they are all in the same suite.
> To multiply that with all the combinations of HC1 and HC will be
> really unpleasant. Moreover, the only thing anyone will ever use after
> a short while is HC, since it is so much cleaner and more effective.
> That means all the HC1 mess and all the testing and interoperability
> investment will be for nothing other than that - just to pass the
> test. But it will generate latent bugs, increase the footprint, and
> frustrate interoperabilty.
>
> So, as we imagine a future of billions of 6LoWPAN IP devices embedded
> in important hard to reach places, lets take the step now to simplify
> their implementation and testing, rather worry too much about saving a
> few hours of coding for the half dozen existing implementations. If
> that is not reason enough, those same implementors will save many
> times that amount in reduced testing and interoperability validation.
> _______________________________________________
> 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
