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

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Daniel Gavelle
> Sent: Thursday, February 25, 2010 15:18
> To: [email protected]
> 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
> > 
> > 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 protected]>
> >>> Subject: [6lowpan] WGLC for 6lowpan HC draft
> >>> To: 6lowpan <[email protected]>
> >>> Message-ID: <1266047791.3643.48.ca...@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 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
> > 
> 
> --
> __________________________________________________
> 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 protected]
> https://www.ietf.org/mailman/listinfo/6lowpan
> 
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan

Reply via email to