Hi Dario,
On Feb 18, 2010, at 5:10 PM, Dario Tedeschi wrote:
I support the effort to make the offset field be in units of single
octets, rather than 8 octets. Though we need to be careful about
shrinking the tag field. Earlier drafts of RFC 4944 originally
made the tag field 10 bits, but some comments from IESG review
raised concerns about whether that was enough. After some
discussion on the list, the decision was made to expand the field
to 16 bits (though only 14 bits was necessary at the time) [1].
The key point is that 802.15.4 may operate on different PHYs with
higher bit rates so we should be prepared for those.
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 based on worst case packet sizes (i.e.
smallest) and a 1Mb/s bit rate:
1st Packet Size = 128 bytes (PHY + MAC + Frag Hdr + HC + data + FCS)
2nd Packet Size = 18 bytes (PHY + MAC{short addrs} + Frag Hdr + 1 +
FCS)
Total bytes sent for one datagram = 128 + 18 = 146
Total bits sent = 146 x 8 = 1168
Bit Rate = 1Mb/s
Time to send one datagram = 1168 / 1Mb/s =~ 1.168ms
**** Assuming datagrams are continuously sent from one source
without delays (unlikely, but lets ignore any delays for now).
Time for 16bit tag field to rollover = 65536 * 1.168ms = 77s
Time for 13bit tag field to rollover = 8192 * 1.168ms = 10s
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.
In my ideal world, we would reallocate a single fragment header
type for simplicity.
I agree. An offset of 0 would indicate the first fragment, anyway
(assuming one fragment header type for all fragments and the offset
included).
Right.
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?
• 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.
Again, this path is following the philosophy of simplifying the
existing fragmentation mechanism. I'm still looking for feedback on
whether people would like to see additional fragmentation mechanisms
at the risk of opening the flood gates.
--
Jonathan Hui
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
