Hi Gab,
I've been thinking some more about the fragmentation issue and
have managed to convince myself that the tag size in the latest draft
(of 1 byte) is adequate :-) My initial analysis assumed two things:
1. That the application would be pumping a lot of data
over a short period of time
2. It would do so using a fairly small packet size that is still
large enough to cause fragmentation (e.g. the analysis
assumed 128 bytes).
We do see 1 on our network already, for example, when over the
air reprogramming is involved and we send 10s of KBs of code.
However, in such situations, an application is also likely to use
large packets -- closer to the 2KB max. (I couldn't think of any
realistic situations where 1 and 2 both apply simultaneously).
If we change 2 to assume large packets, the analysis changes
quite a bit. Assuming 1-2KB packets, 8-bit sequence numbers
will roll around only after an application has pumped out
256-512KB of data which, at 250kbits/s (or more realistically
~16KB/s), would take about 16-32 seconds -- reasonable
enough for a reassembly timer. In reality, these values might be
even higher because few sensors (the Sun SPOT being an exception)
have enough memory to buffer 256-512KB of data.
vipul
On Oct 24, 2005, at 3:44 PM, gabriel montenegro wrote:
Vipul,
--- Vipul Gupta <[EMAIL PROTECTED]> wrote:
If we assume that the LowPAN design this group comes up
with will only need to be revised when a new lower layer
is designed, then yes there is no need for version numbers.
However, if there's even a small chance that, based on
deployment experience, we may revise the LowPAN
header format while still wanting to run it on top of the
same lower layer then I don't see how the recipient
would figure out how to interpret the received packet
without a version number. From what I can tell, there is
Yes, there is that risk. I guess the more complex an encapsulation,
the more justifiable it is to have a version field.
no place in the 802.15.4 header to describe the higher
protocol type
Correct, 802.15.4-2003 does not. But as an 802 technology, you're
supposed to use
802.2 LLC (section 5.3 in the 15.4 spec), which we've abandoned
because of its overhead.
Instead, we provide our own protocol field within the lowpan layer.
(ethernet, in contrast, does have such a
field).
Well, the 802.3-2002 spec talks about a Type/Length field.
When one uses the "ethernet II" frame format, this field
is interpreted as "Type", so what you say is true. But when you
use the other available formats (802.3, 802.2 LLC, SNAP/RFC1042)
then this field is interpreted as "Length". In these cases, the
ethernet frame does not have such a type field, and this is
left to the higher layer encapsulation, e.g., 802.2 LLC or
the LLC-derived SNAP encapsulation.
Notice that none of the basic ethernet frame, LLC or SNAP have a
version field.
Our LoWPAN encapsulation is somewhat similar in function to
the 802.2 LLC. It is a bit more complex. A much closer analogy is the
encapsulation format defined in section 4.2 of the "IPv4 over IEEE
1394"
(RFC 2734) spec (not suprisingly, as this was the model for our
adaptation
layer at the start). Again, this encapsulation does not have a version
field
either.
So I wonder, if a version field was deemed superfluous for all the
above
encapsulation formats (which did not have the stringent constraints we
do),
why would it be justified in our case? Our complexity is similar to
that
of the encapsulation for IEEE 1394. One thing we do in addition to
what they
do is have a mesh header. Is this additional complexity enough to
justify adding
a version header?
Perhaps the following example will make things clearer.
Because SSL includes a version number, the IETF was
able to define TLS and now TLS 1.1 without requiring
a new underlying protocol (all versions of SSL and
TLS run atop TCP).
Like I said, the more complex an encapsulation, the more chances you'll
want a version field in there. For higher layer protocols like HTTP,
TLS/SSL, SSH, etc, you definitely want one. No question there. But
protocols
at those layers are hardly applicable to what we're doing. When I look
at
what I believe is applicable (frame formats as discussed above), I
have not
seen version numbers. Perhaps we've just added enough complexity to
just
tilt the balance enough that we should use one. Not sure yet. I'd
certainly
like to hear from implementors and people deploying this stuff. I
didn't add
the version field before this submission cuz I think we need more
discussion
(and frankly, cuz I didn't have time).
Let's discuss some more.
It seems like a prudent tradeoff to me to spend 2 bits
for the ability to later revise LowPAN (based on deployment
experience) without requiring a new lower layer.
As for the tag size, I think 7 bits is still too low (based on
the previously posted analysis). If the general consensus
That analysis is a theoretical one. I'm quite unconvinced that we'll
ever hit this in practice given the type of applications that 15.4 is
for (after all, the max frame size is remarkably puny). I think before
over-engineering this is one point that requires input from folks
actually
deploying (hopefully comercially) 15.4 networks.
is to bump it to 10 and wait for deployment experience
before changing it to a higher value, that's fine (at current
data rates, 10 bits would allow for a reassembly timeout of
around 8 seconds which might be ok).
From RFC 2734 I note that the 1394 encapsulation uses a datagram tag
length of 16 bits.
Comparing with the lowest speed or 100Mbps in RFC 2734 (with an MTU of
512 octets), it
seems like there's a factor of slightly under 2^8 as compared to
802.15.4's
expected max throughput of 125Kbps at 128 octets MTU. If so, and given
that
1394 is *MUCH* more probable to transfer long packets than 802.15.4,
I'd say for us a datagram tag of 8 bits is at least equivalent (and in
reality much safer, given expected usage) than their 16 bits.
In keeping with this reasoning, and if we determined that a version
field was useful,
I'd suggest taking 2 bits from the tag (bumping it down to 8 bits as
per the previous
paragraph).
In terms of saving bits, supporting short addresses
provides the biggest bang for the buck -- instead
of carrying two 8-byte addresses across each hop
(for a multihop pkt), carrying two 2-byte addresses
saves 96 bits. Compared to this, the extra few
bits spent on the version or the tag are minuscule.
Agree, small addresses are the best bang for the buck. The latest
version of
the draft supports these. But I don't think we can claim that by doing
so we
are being particularly good citizens. This is a savings enabled
fundamentally by the 802.15.4 spec regardless of us.
On the contrary, *not* supporting short addresses
would have made us bad citizens. We only become good citizens by being
careful about the
stuff we are adding. That stuff is the fixed overhead in the
encapsulation formats.
The first version had very little overhead, and we've been growing it
slowly.
-gabriel
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
