Subject: [6lowpan] HC

From: "David Culler" <[email-masked]>
Date: Wed, 16 Jul 2008 09:25:14 -0700

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-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 17 Jul 2008 10:13:56 +0200

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-masked] [mailto:[email-masked]] On
Behalf Of David Culler
Sent: mercredi 16 juillet 2008 18:25
To: [email-masked]
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.

---

From: Zach Shelby <[email-masked]>
Date: Thu, 17 Jul 2008 11:35:35 +0300

I support this motion fully. This is the time to do it, getting stuck 
with both HC1 and HC not only complicated implementation, testing and 
validation. It also slows down technology acceptance by confusing 
engineers and users. A couple questions come to mind:

- Timeline would need to be quick, end of this year at the latest. Could 
we manage that or better?
- How would the depreciation be done in practice? I guess a new complete 
RFC would be issued, and the whole RFC4944 depreciated.

- Zach

David Culler wrote:
> ------------------------------------------------------------------------
> 

-- 
Zach Shelby | Head of Research | +358 40 7796297
Sensinode Ltd.   www.sensinode.com
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: IGARASHI Yuichi <[email-masked]>
Date: Thu, 17 Jul 2008 17:40:25 +0900

Hi David,

I support your approach, too.
The test for interoperability is increased by complicating specifications.
Implementers never want that, I think.

Yuichi

--
 Hitachi, Ltd., Systems Development Laboratory
 IGARASHI Yuichi
 Mail： yuichi.igarashi.hb@.hitachi.com
 Tel ： +81-(0)45-860-3080
 FAX ： +81-(0)45-860-1674
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Anthony Schoofs <[email-masked]>
Date: Thu, 17 Jul 2008 10:56:24 +0200

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-masked]

                                                                        To 
                                       "David Culler"                      
                                       <[email-masked]>            
     "Pascal Thubert                   <[email-masked]>                  
     (pthubert)"                                                        cc 
     <[email-masked]>                                                  
                                                                   Subject 
     Sent by:                          Re: [6lowpan] HC                    
     6lowpan-bounces@ietf                                   Classification 
     .org                                                                  
                                                                           
     17-07-2008 10:13                                                      

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-masked] [mailto:[email-masked]] On Behalf
Of David Culler
Sent: mercredi 16 juillet 2008 18:25
To: [email-masked]
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.

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.

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.

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 17 Jul 2008 08:54:41 -0600

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:
> 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
> Inactive hide details for Pascal"Pascal Thubert (pthubert)"
> <[email-masked]>
> 
> 
>         "Pascal Thubert (pthubert)"
>         <[email-masked]> 
>         
>         Sent by:
>         [email-masked] 
>         
>         17-07-2008 10:13
>         
> 
>                To
> 
> "David Culler"
> <[email-masked]>
> <[email-masked]>
> 
>                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.
> ______________________________________________________________________
> 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.
> 
> 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.
> 
> 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).
> 
> 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.
> 
> 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.

---

From: "Stephen Dawson-Haggerty" <[email-masked]>
Date: Thu, 17 Jul 2008 17:40:03 -0700

I'd like to weigh in with a few notes that people on this list might
be interested in.  First, I've released the Berkeley 6lowpan
implementation for TinyOS into tinyos-2.x-contrib/berkeley/b6lowpan
under a BSD license.  It is still very much a work in progress, but it
should be useful to anyone wanting to experiment with 6lowpan.  It
uses HC for header compression and IPv6 stateless autoconf for prefix
assignment.  It provides UDP as the transport, and supports multi-hop
routing.  Standard tools like ping6, nc6, and tracert6 all work with
the stack.  More information is available on the project wiki
(http://smote.cs.berkeley.edu:8000/tracenv/wiki/b6loWPAN).

Second, it might be useful to (re)start the conversation about HC.
Overall, it's relatively clean and easy to implement; many of the
implementation choices surrounding a 6lowpan stack aren't really that
affected by how headers are compressed.  There are a couple of things
neither the draft nor 4944 directly address, though:

 - support route-over combined with no hop-by-hop reassembly
 - support source routing

As older discussions on the list have gone over, the first is
currently possible by unpacking the IP headers in the first fragment
and caching the routing information for successive fragments.  I think
it's probably not necessary to do anything other then declare that the
compressed IP headers must fit into the first fragment, but there
could be other ideas for how to best allow this.

The second belongs in any standard, because it interacts with address
compression: the source route can be used to infer the source and
destination IP address for intra-pan routing.  What I would suggest
here is the addition of an LOWPAN_HCNH encoding for source routing.
This also brings up the issue it should be possible to follow this
header (NHSR?) with a NH_UDP encoding block so as to have compressed
source routing as well as UDP headers.  Whatever header format is
decided on should also support a record route option in the dispatch
byte.  If people agree that this is important, I can write up a
proposal on how to do this.

What else do people see as needing work in HC?

Steve

On Thu, Jul 17, 2008 at 7:54 AM, Geoff Mulligan <[email-masked]> wrote:
>> I do support that approach. I'd note that it would impose some

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 17 Jul 2008 19:13:06 -0700

Hi Stephen, see below:

> - support route-over combined with no hop-by-hop reassembly

We should clean up the terminology here since the working group seems  
to have different ideas of what "route-over" is. I admit, that I  
haven't been that clear myself over the past few months. I'd like us  
to decouple routing from forwarding in the way that IP has  
traditionally done. So it's probably more appropriate to say L3  
forwarding in this context. Route-over is a term meant to describe IP  
routing rather than L2 mesh routing.

> could be other ideas for how to best allow this.

Yes. Some are concerned that this adds some state/complexity within  
the node. I'm not convinced that the added resource requirements are a  
huge issue. As for fitting into the first fragment, even an  
uncompressed IPv6 header should fit given the worst case. Unless you  
have a huge hop-by-hop options header or large (yet-to-be-defined)  
6lowpan headers, this shouldn't be much of an issue.

> proposal on how to do this.

I can say that we've been using such functionality in production  
deployments for many months now and they are invaluable resources for  
debugging wireless networks (especially when routing protocols fail)  
and can be used for simple routing protocols as well (e.g. DSR-like  
protocols). While they do interact with HC, I did not include them in  
the first draft simply because it was more important to solve the  
initial problem of proposing a new HC format. Furthermore, routing  
type 0 was just deprecated and there is no existing definition for  
record-route in IPv6. I'm strongly in favor of including this  
functionality in the draft, but we need to be careful about the  
processing rules. If the working group things this is useful  
functionality to include in the doc, I'd be happy to see your ideas  
and we can compare with mine or others.

> What else do people see as needing work in HC?

Some of the issues on the plate that I plan to address in the next  
draft (as discussed in the last WG meeting):
- two bits for HLIM to indicate where the packet came from
- adding bits to identify the prefix context for supporting multiple  
prefixes
- removing option for checksum compression in UDP
- add a new UDP-like transport that relies on end-to-end MIC rather  
than checksum

Chairs, given the urgency of pushing HC through, I'd like to have some  
time at the WG meeting to talk about updates and issues. Thanks.

To answer the original question in this thread: I too am in favor of  
deprecating HC1 and pushing HC forward as quickly as possible.

--
Jonathan Hui