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.
Pascal Thubert (pthubert) wrote:
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 protected] [mailto:[email protected]] On
Behalf Of Daniel Gavelle
Sent: Thursday, February 25, 2010 3:18 PM
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
--
__________________________________________________
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
