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

From: Zach Shelby <[email-masked]>
Date: Mon, 1 Mar 2010 10:01:17 +0200

I am in favor of moving the HC draft to the IESG with the minimal changes needed wrt fragmentation.

TCP header compression is a whole different beast (and a different charter), and in my opinion RPL specific message optimization should be left to the ROLL WG.

Zach

On Feb 25, 2010, at 9:21 , Jonathan Hui wrote:

> 
> 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
>> Robert Cragie (Pacific Gas & Electric)
>> 
>> Gridmerge Ltd.
>> 89 Greenfield Crescent,
>> Wakefield, WF4 4WA, UK
>> +44 (0) 1924 910888
>> http://www.gridmerge.com
>> 
>> 
>> 
>> Reddy, Joseph wrote:
>>> 
>>> 
>>> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> **************************************
>>> _______________________________________________
>>> 6lowpan mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/6lowpan
>>> 
>>> 
>> _______________________________________________
>> 6lowpan mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/6lowpan
> 
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

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.

---

From: Zach Shelby <[email-masked]>
Date: Mon, 1 Mar 2010 10:06:00 +0200

On Feb 26, 2010, at 12:32 , Anders Brandt wrote:

> 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

This makes sense. Although I don't see a reason for the transition period. Why not just depreciate the old dispatch in the HC draft as it updates RFC4944.

Zach

> 
> Cheers,
>  Anders
> 
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Daniel Gavelle
>> Sent: Thursday, February 25, 2010 15:18
>> To: [email-masked]
>> Subject: Re: [6lowpan] WGLC for 6lowpan HC draft
>> 
>> 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:
>>> 
>>> 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
>>> 
>>>> I concur with Joseph's statements and thus do not support 
>> forwarding 
>>>> the draft to IESG yet.
>>>> 
>>>> Robert
>>>>> 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 )
>>>>> 
>>>>> 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.
>>>>> 
>> __________________________________________________
>> 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 
>> __________________________________________________

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND