Subject: Re: [6lowpan] WGLC for 6lowpan HC draft

From: "Reddy, Joseph" <[email-masked]>
Date: Wed, 24 Feb 2010 13:01:57 -0600

Hi Geoff,

I do not support forwarding this doc to IESG yet. I would like the following issues addressed 

** Investigate possible TCP header compression scheme

** Explain strategy for compressing RPL headers ( I understand this could be done in the ROLL group, but I have not seen a definite statement either way )

** Resolve the "forward compatability" issue ( ideally, while maintaining backwards-comptability )

-Regards, Joseph

----------------------------------------------------------------------

Message: 1
Date: Sat, 13 Feb 2010 00:56:31 -0700
From: Geoff Mulligan <[email-masked]>
Subject: [6lowpan] WGLC for 6lowpan HC draft
To: 6lowpan <[email-masked]>
Message-ID: <1266047791.3643.48.camel@dellx1>
Content-Type: text/plain

Folks,
  I realized that I have made a huge slip-up.  The HC draft has languished for the past few months.
At the meeting in Hiroshima we said that we would last call this draft, but I failed to send out the actual last call. So...

  This note formally starts the WG Last Call for comments on draft-ietf-6lowpan-hc-06, "Compression Format for IPv6 Datagrams in 6LoWPAN Networks".

The document can be found at:
http://www.ietf.org/id/draft-ietf-6lowpan-hc-06.txt

The document is intended to be submitted by this Working Group to the IESG for publication as a Standards Track document.

Please review the document carefully (one last time), and send your comments to the 6lowpan list.  Please also indicate in your response whether or not you think this document is ready to go to the IESG.

Because of my gaffe this Last Call will end Wednesday February 24 2010 at 2359 UTC.

        Thanks,
                Geoff

**************************************

---

From: "Rene Struik" <[email-masked]>
Date: Wed, 24 Feb 2010 16:00:41 -0500

Hi Geoff:

When studying details of the RoLL protocol, a similar question as the
one raised by Joseph Reddy came to mind: how are we going to ensure that
all packets are not going to be as bulky as they seem right now (from
rpl-6, it seems one may use tens of bytes in various packets, seemingly
without any technical need). As I understood from the RPL Security conf
call as of Tue Feb 23, 2010, 12-1pm EST, compression of IPv6 packets is
not in RoLL's charter and would be 6lowpan's responsibility. So, at this
time, I would like this issue to be adequately addressed (if not
6lowpan, who is going to do this), prior to moving this forward to IESG.

Best regards, Rene

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Reddy, Joseph
Sent: Wednesday, February 24, 2010 2:02 PM
To: [email-masked]
Subject: Re: [6lowpan] WGLC for 6lowpan HC draft

Hi Geoff,

I do not support forwarding this doc to IESG yet. I would like the
following issues addressed 

** Explain strategy for compressing RPL headers ( I understand this
could be done in the ROLL group, but I have not seen a definite
statement either way )

** Resolve the "forward compatability" issue ( ideally, while
maintaining backwards-comptability )

-Regards, Joseph

Message: 1

Folks,
  I realized that I have made a huge slip-up.  The HC draft has
languished for the past few months.
At the meeting in Hiroshima we said that we would last call this draft,
but I failed to send out the actual last call. So...

  This note formally starts the WG Last Call for comments on
draft-ietf-6lowpan-hc-06, "Compression Format for IPv6 Datagrams in
6LoWPAN Networks".

The document is intended to be submitted by this Working Group to the
IESG for publication as a Standards Track document.

Please review the document carefully (one last time), and send your
comments to the 6lowpan list.  Please also indicate in your response
whether or not you think this document is ready to go to the IESG.

Because of my gaffe this Last Call will end Wednesday February 24 2010
at 2359 UTC.

        Thanks,
                Geoff

**************************************
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Robert Cragie <[email-masked]>
Date: Thu, 25 Feb 2010 06:55:16 +0000

Hi Geoff,

I concur with Joseph's statements and thus do not support forwarding the 
draft to IESG yet.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com <http://www.gridmerge.com/>

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 24 Feb 2010 23:21:28 -0800

It would be helpful to know what people's expectations are relative to  
what this specific draft should include relative to an acceptable  
timeline of getting a document out.  Few comments:

- The WG currently does not have a proposal for TCP header  
compression, let alone one that we have built some consensus around.
- The RPL protocol mechanisms and headers are still in flux.  It is  
difficult to propose a concrete way of compressing them without  
knowing what they will look like.  For example, within ROLL, we will  
be proposing ways to "pack" lists of addresses such that common  
prefixes are only carried once within the datagram.
- The general 6lowpan-hc format is generic enough to be used on top of  
other fragmentation mechanisms and/or frame sizes.  Do we really want  
to limit its capabilities to a particular fragmentation and frame size?

There always seems to be a tension between splitting functionality  
across different drafts vs. delaying the current draft to "sneak" in  
new functionality.  I'm all for sneaking in fixes to RFC 4944  (i.e.  
simple changes to fragmentation) or additional functionality for  
expediency if we can realize that expedience.  But waiting until we  
design a TCP header compression mechanism that we can build consensus  
around probably isn't the best approach, in my opinion, and should be  
left to a separate draft.

So what do others think?

(I will start a new thread specifically on fragmentation + forward- 
compatibility so that we drive towards closure on that specific issue).

--
Jonathan Hui

On Feb 24, 2010, at 10:55 PM, Robert Cragie wrote:

> Hi Geoff,
>
> I concur with Joseph's statements and thus do not support forwarding  
> the draft to IESG yet.
>
> Robert
> http://www.gridmerge.com
>> At the meeting in Hiroshima we said that we would last call this  
>> draft, but I failed to send out the actual last call. So...
>>
>>   This note formally starts the WG Last Call for comments on draft- 
>> ietf-6lowpan-hc-06, "Compression Format for IPv6 Datagrams in  
>> 6LoWPAN Networks".
>>
>> The document is intended to be submitted by this Working Group to  
>> the IESG for publication as a Standards Track document.
>>
>> comments to the 6lowpan list.  Please also indicate in your  
>> response whether or not you think this document is ready to go to  
>> the IESG.
>>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Feb 2010 08:44:19 +0100

> ** Explain strategy for compressing RPL headers ( I understand this could be done in the ROLL group, but I have not seen a definite statement either way )

Joseph,

I appreciate your comments.

I do have to point out that the work item on header compression this WG was chartered with has a defined scope:

> 2. Produce "6LoWPAN Improved Header Compression" to describe
> mechanisms to allow enhancements to the 6LoWPAN headers. Specifically
> this document will describe compression of addresses that are not
> link-local. Additionally this document may include other enhancements
> or optimizations of the HC1 or HC2 6LoWPAN headers.

The one feature that was explicitly called out was compressing global addresses, and I haven't heard any complaints on the way HC-06 addresses that item.
There are also "other enhancements or optimizations" in HC-06, in the rather subordinate sense this was meant here.

Having been part of the five-year effort that produced RFC4996, I'm pretty sure TCP header compression would be on a different timeline, and on a different scale altogether.  
It is way beyond what we had in mind when we discussed and agreed the above charter item.
(Yes, a less complex and less efficient form of header compression than RFC4996 can be found, but this is still likely to be a couple years of effort.)

I also believe that RPL might very well address its header space problems in its own protocol -- in any case, with RPL still being in flux, covering RPL would also be a different timeline.

We have to deliver on our commitments before we start new work.
We are already late meeting our milestone:

> Aug 2008	 	Submit Improved Header Compression document to IESG for consideration as a proposed standard

> ** Resolve the "forward compatability" issue ( ideally, while maintaining backwards-comptability )

I think this comment is the key to resolving the above issues -- can we discuss now how we would embrace, e.g., TCP header compression (or RPL compression if header size issues are not addressed by RPL), later?

Gruesse, Carsten

---

From: "Colin O'Flynn" <[email-masked]>
Date: Thu, 25 Feb 2010 09:35:20 -0000

Hi Jonathan,

I support your comments completely here. Adding TCP compression in another
draft would give us lots of time to design & test it, as the TCP compression
will be more complex than UDP. 

I think almost any node will need to support UDP as a matter of normal
operation. But not all nodes will support TCP, many may just use UDP. Hence
it makes sense for that reason to keep TCP out of the HC.

In addition I would like to see the issue of MUSTs worked out. The current
I-D doesn't explicitly specify what features / addressing modes you must
support. 

Having this document moving towards RFC status would be a great boost to
implementers & 6LoWPAN. Then you can  simply say you support "RFC4944 +
RFCDEADBEEF", and other people know what frame format you are using. Right
now it's "well I support -hc-01" and someone else supports -05, and someone
else supports -06 but not all functions.

Regards,

   -Colin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jonathan Hui
Sent: February 25, 2010 7:21 AM
To: [email-masked]
Cc: [email-masked]; Reddy, Joseph
Subject: Re: [6lowpan] WGLC for 6lowpan HC draft

So what do others think?

--
Jonathan Hui

---

From: Daniel Gavelle <[email-masked]>
Date: Thu, 25 Feb 2010 14:18:07 +0000

On the subject of forward and backward compatibility, I think the 
dispatch codes for fragmentation (FRAG1, FRAGN) should be changed to 
values that are currently reserved if we move to sending the 
datagram_size and datagram_offset as compressed and uncompressed values. 
  This will mean that during the transition period, it will be much 
easier to sort out interoperability problems where some nodes use 
compressed values and some nodes are running older code using 
uncompressed values.

I don't think the new nodes should support both compressed and 
uncompressed offsets / sizes but should simply reject fragments that 
don't have the dispatch codes they are expecting.

The existing dispatch codes would not be lost forever as they could be 
strongly deprecated and then recycled in a future RFC.

Daniel.

Jonathan Hui wrote:
> - The WG currently does not have a proposal for TCP header compression, 
> let alone one that we have built some consensus around.
> difficult to propose a concrete way of compressing them without knowing 
> what they will look like.  For example, within ROLL, we will be 
> proposing ways to "pack" lists of addresses such that common prefixes 
> are only carried once within the datagram.
> other fragmentation mechanisms and/or frame sizes.  Do we really want to 
> limit its capabilities to a particular fragmentation and frame size?
> 
> across different drafts vs. delaying the current draft to "sneak" in new 
> functionality.  I'm all for sneaking in fixes to RFC 4944  (i.e. simple 
> changes to fragmentation) or additional functionality for expediency if 
> we can realize that expedience.  But waiting until we design a TCP 
> header compression mechanism that we can build consensus around probably 
> isn't the best approach, in my opinion, and should be left to a separate 
> draft.
> 
> So what do others think?
> 
> (I will start a new thread specifically on fragmentation + 
> forward-compatibility so that we drive towards closure on that specific 
> issue).
> 
> -- 
> Jonathan Hui
> 

-- 
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371  Registered In England
http://www.jennic.com
__________________________________________________

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 25 Feb 2010 18:23:25 +0100

Hi Daniel:

I agree that we need to rework fragments for sure, but I'd think that:

-  there's more to do than just swap from uncompressed offsets to
compressed
- this is not the right draft to discuss fragmentations

My suggestion is that we add some lines that explain the problem and
suggest to limit the compressed piece to the first fragment if the
RFC4944 fragmentation is used, and move forward with this draft.

And then let's work (separately) on fragments. Lots to do there:
- recovery
- ECN
- forwarding in route over mode
...

And then we can work on compressing TCP, RPL, routing headers, etc...,
all things in due time with due priority, as determined by our
(re)charter. 

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Daniel Gavelle
Sent: Thursday, February 25, 2010 3:18 PM
To: [email-masked]
Subject: Re: [6lowpan] WGLC for 6lowpan HC draft

Daniel.

> forward-compatibility so that we drive towards closure on that 
> specific issue).
> 
> --
> Jonathan Hui
> 

--
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371
Registered In England http://www.jennic.com
__________________________________________________
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Daniel Gavelle <[email-masked]>
Date: Thu, 25 Feb 2010 18:16:17 +0000

Pascal,

I am happy with HC-06 passing the last call and going to IESG unchanged, 
with the offset and length uncompressed.  As you say, the fragmentation 
  issues can be addressed by a separate draft.

However, if the weight of opinion is that the change to compressed 
offsets should be made in the HC-06 draft then I think we should also 
change the dispatch headers to identify the change.

Daniel.

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 26 Feb 2010 11:32:14 +0100

Hi

I support the proposal of a simple correction to fragmentation:

* new dispatch codes for generic datagrams -
  fragments may carry compressed or uncompressed; it does not matter.

* reject fragments of old type in the transition period

* strongly deprecate old dispatch code by 2011

Cheers,
  Anders

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Daniel Gavelle
> Sent: Thursday, February 25, 2010 15:18
> To: [email-masked]
> On the subject of forward and backward compatibility, I think 
> the dispatch codes for fragmentation (FRAG1, FRAGN) should be 
> changed to values that are currently reserved if we move to 
> sending the datagram_size and datagram_offset as compressed 
> and uncompressed values. 
>   This will mean that during the transition period, it will 
> be much easier to sort out interoperability problems where 
> some nodes use compressed values and some nodes are running 
> older code using uncompressed values.
> 
> I don't think the new nodes should support both compressed 
> and uncompressed offsets / sizes but should simply reject 
> fragments that don't have the dispatch codes they are expecting.
> 
> The existing dispatch codes would not be lost forever as they 
> could be strongly deprecated and then recycled in a future RFC.
> 
> Daniel.
> 
> 
> 
> Jonathan Hui wrote:
> > 
> Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg 
> No: 3191371  Registered In England http://www.jennic.com

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 26 Feb 2010 12:44:33 +0100

Hello René:

As a RPL editor I'd point out that RPL operates on any LLN, not only links running 6LoWPAN. So RPL cannot waste humongous space in the packets and then rely of 6LoWPAN to fix it.

RPL will have to do its own exercise and get as lean as possible; I admit there's a lot left to be done, in particular in source route and DAO, and that WILL be done. Whether 6LoWPAN can do more for its own context is left to be seen, and we can start a new draft for that purpose if such need is determined.

The real question is for me whether the HC draft as it stands enables future additions such as may be needed for RPL, or if it would stand on the way. For all I see, HC leaves the door open for additions in particular new headers such as the one RPL is considering for loop detection, so I do not see this draft as compromising RPL.

As you figure, there will always be additions that can be made, new types and header coming up, new transports to integrate. This draft is not intended to cover everything that will ever be compressed in 6LoWPAN and I hope/trust that additions will follow. Till then, there are implementations and deployments waiting for this draft to become RFC, and we need to move forward. I do support moving this work forward to IESG, see what they think.

Cheers,

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rene Struik
Sent: Wednesday, February 24, 2010 10:01 PM
To: [email-masked]
Subject: Re: [6lowpan] WGLC for 6lowpan HC draft

Hi Geoff:

When studying details of the RoLL protocol, a similar question as the one raised by Joseph Reddy came to mind: how are we going to ensure that all packets are not going to be as bulky as they seem right now (from rpl-6, it seems one may use tens of bytes in various packets, seemingly without any technical need). As I understood from the RPL Security conf call as of Tue Feb 23, 2010, 12-1pm EST, compression of IPv6 packets is not in RoLL's charter and would be 6lowpan's responsibility. So, at this time, I would like this issue to be adequately addressed (if not 6lowpan, who is going to do this), prior to moving this forward to IESG.

Best regards, Rene

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Reddy, Joseph
Sent: Wednesday, February 24, 2010 2:02 PM
To: [email-masked]
Subject: Re: [6lowpan] WGLC for 6lowpan HC draft

Hi Geoff,

-Regards, Joseph

Message: 1

Folks,

        Thanks,
                Geoff