Hi Pascal,
Yes, you are right - hc-01 supports all header values (just carry
everything in-line).
Regarding Julien's comments, I think hc-01 and the format proposed to
support Julien's cases are straight-forward to implement. I think the
more important issue is whether Julien's cases will be common in
6LoWPAN applications. We (Arch Rock) do not commonly use the cases
that Julien wishes to add compression for. But if Julien/others can
demonstrate a strong need for them (i.e. cases that will be used
fairly often in relevant 6LoWPAN applications), then I do think we
should consider them. Julien, can you explain important commonly used
cases that would not be supported by hc-01?
--
Jonathan Hui
On Oct 10, 2008, at 9:41 AM, Pascal Thubert (pthubert) wrote:
Hi Jonathan
Maybe a good reason to stick to the current format and change the
misleading wording around it, what do you think? In any case, I'm all
for starting 4944bis and recoverable frags today, though.
Pascal
-----Original Message-----
From: Jonathan Hui [mailto:[EMAIL PROTECTED]
Sent: vendredi 10 octobre 2008 18:02
To: Pascal Thubert (pthubert)
Cc: Carsten Bormann; Geoff Mulligan; [email protected]
Subject: Re: [6lowpan] rfc4944, hc and dispatchs
Hi Pascal:
I'm for pushing HC through as quickly as possible. We are already
behind according to the charter text.
The one dependency I see is the structure of the dispatch byte. If we
choose a dispatch value(s) that is compatible with RFC 4944, then we
are fine, I think. But if we want extra bits by changing the layout
of
the dispatch values/identifiers for Frag/Mesh headers (as both I and
Julien have proposed) then this creates a dependency on defining that
new dispatch assignment scheme.
--
Jonathan Hui
On Oct 10, 2008, at 8:51 AM, Pascal Thubert (pthubert) wrote:
I'm all with you, Jonathan, as long as that does not delay HC.
This is why I proposed a structured set of document that leaves HC
with
its current scope as opposed to making it a full revision of 4944.
Makes
sense?
Pascal
-----Original Message-----
From: Jonathan Hui [mailto:[EMAIL PROTECTED]
Sent: jeudi 9 octobre 2008 21:17
To: Pascal Thubert (pthubert)
Cc: Carsten Bormann; Geoff Mulligan; [email protected]
Subject: Re: [6lowpan] rfc4944, hc and dispatchs
In general, I'm in support of Pascal's proposal. Cleaning up the
format to use a stacked-header format was just one of the items and
there were many other things we wanted to fix before pushing out
RFC
4944. But we were far too late to the game in doing a complete
overhaul of the doc. I think *now* is the time to make improvements
to
RFC 4944.
--
Jonathan Hui
On Oct 9, 2008, at 10:41 AM, Pascal Thubert (pthubert) wrote:
Hi Carsten:
Some implementations and dependant standards would require a
timeline
for this. Leaving it up in the air does not help our users do
their
product planning?
Considering the attention and the work on the new LOWPAN_IPHC, I
expect
that we'll be ready for WGLC after 2/3 more respins. That could be
achieved by Minneapolis time if we can rally all interested
parties
to
comment on the existing published spec. So could you chairs
please:
propose a time line to the WG along those lines
<<<<<<<<<<<<
raise WG attention on this work?
<<<<<<<<<<<<
Also by or at Minneapolis, my sensation is that we should not only
discuss the terms of deprecating RFC 4944 HC but also consider the
spec
as a whole:
- Mesh Header is a layer violation. I talked to implementers and
their
message is that they do not use it because it's never exactely
what
that
specific radio needs; so they end up with their own mesh header
anyway
and will not duplicate things for the sake of comliance. Instead
we
might need a Routing header, pretty useful for source routing in
route
over.
- Fragments are not recovered individually. We have enough
experience to
know where that leads should a 6LoWPAN network experience either
high
load or high BER. We have a draft on the works to deprecate that
with
recoverable fragments.
- The Current HC WG doc covers all the compression cases in RFC
4944,
bigger and badder.
So what's left?
My proposal is to start a 4944bis that would focus on the
addressing
architecture, would be the placeholder to control the dispatch
type
but
would defer to the drafts/RFCs that actually detail the operation
of
each dispatch type.
What do you think?
Pascal
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
Behalf Of Carsten Bormann
Sent: jeudi 9 octobre 2008 16:43
To: Julien Abeille (jabeille)
Cc: Carsten Bormann; [email protected]
Subject: Re: [6lowpan] rfc4944, hc and dispatchs
On Oct 09 2008, at 16:09, Julien Abeille (jabeille) wrote:
- does it officialy deprecate the old header compression scheme?
My impression of the mailing list consensus is that this is what
the
WG wants to achieve.
At the time this was discussed, I cautioned that it is premature
to
decide on replacing something existing with known flaws with
something
not yet quite cooked (and, hence, with unknown flaws).
So I expect we'll ultimately decide this question at the time HC
and
the related specs come up for WGLC.
Clearly, the stated intention of many WG members is to make this
happen, as it would be wasteful to support two HC schemes in tiny
implementations.
Gruesse, Carsten
_______________________________________________
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
