Hi Jonathan
Jonathan Hui wrote:
Hi Dario,
On Feb 18, 2010, at 5:10 PM, Dario Tedeschi wrote:
What kind of future bit rates are expected? Isn't it also possible
that even a 16bit tag might not be enough in the future, if bit rates
increase enough. My point here, is that I think the tag size is
somewhat subjective depending on who you talk to and how much of the
future one tries to predict.
When this WG chose to expand the tag field, we considered 2 Mbps 15.4a
PHY - see the archived thread that I linked.
Here's a rough calculation of the time it would take for the tag
value in one node to rollover ... --- removed for brevity --- ...
So is a 9 second rollover at 1Mb/s not sufficient as a worst case? I
think it would be OK. Also, if we see bit-rates for PHYs increase we
may also see an increase in allowable packet sizes (one can only hope
:-).
This WG assumed a minimum roll-over period of 60 seconds - following
the parameters chosen by IPv6 reassembly - again, see the archived
thread. I could also see some scenarios where 9 seconds may not be
enough for some low-power protocols and/or mesh-under networks.
However, if it means re-opening a heated debate or causing IESG
problems, perhaps its best to stay with a 16bit tag and avoid wasting
valuable time.
This is what I'm trying to avoid.
OK, fair enough. 16bits it is.
I'm not concerned about backwards compatibility given that we are
changing the entire HC format. And little has been done in the way
of multi-vendor interoperability with the existing formats. In that
case, we include the tag, size, and offset fields in every fragment
while keeping the tag 16 bits and others 11 bits. The header type
would remain at two bits with '11'.
Sounds plausible, except that I have two reservations:
• Having a dispatch pattern of '11xxxxxx' would overlay FRAG1,
FRAGN and LOWPAN_NHC encoding in "draft...-hc-06". FRAG1 and FRAGN
are of greater concern, because there would be no way of filtering
out old fragment headers. I think in this case we'd want to remain
backward compatible.
I'm still not convinced on the *need* for backwards compatibility.
Another option is to take over the NALP value and require any non-IPv6
protocol operating within a 6LoWPAN network to allocate a dispatch
value and respect the dispatch encoding. Are there people using the
NALP value and would they strongly oppose losing another 6 bits to
respect the dispatch encoding in order to fit in simplified fragment
header?
Certainly a possibility, if we are willing to drop NALP.
• The _size and _offset fields would no longer be octet aligned
(assuming the same field order).
It's easy to fix some of that by reordering the fields to: offset |
size | tag.
OK, that would only align "size" and "tag". Ideally I'd rather see all
fields aligned, but given that aligning two 11bit fields is awkward, I'd
rather see offset aligned since that's the one field that's used more
often. How about: tag | size | offset (still assuming a philosophy of
simplifying fragmentation)?
--
Dario
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
