Thanks for sharing this work, Phil.
Is there anything in there that would prompt you to suggest a change in the
base format document?
Most of the points raised seem particularly relevant
to the design of the routing protocols. As you know, the format document
does not do this, so I'm wondering how much (if anything) is relevant to it
as opposed to the routing specifications for lowpan (of which there are
several drafts in existence). One could add some text calling for better
feedback from the link-layer (as the paper recommends), but I cannot see
what difference this would make on the actual protocol, as in, "bits in the air".
I noticed that the first point about links being bimodal leads to some text
in the paper that points out a potential flaw in the current fragment reassembly
logic.
In particular, your paper points out some issue with this text in the format document:
If a link fragment is received that overlaps another fragment as
identified above, the fragment(s) already accumulated in the
reassembly buffer SHALL be discarded. A fresh reassembly may be
commenced with the most recently received link fragment. Fragment
overlap is determined by the combination of datagram_offset from the
encapsulation header and "Frame Length" from the 802.15.4 PPDU packet
header.
The text in the paper mentions an issue with duplicate fragments:
identified above, the fragment(s) already accumulated in the
reassembly buffer SHALL be discarded. A fresh reassembly may be
commenced with the most recently received link fragment. Fragment
overlap is determined by the combination of datagram_offset from the
encapsulation header and "Frame Length" from the 802.15.4 PPDU packet
header.
The text in the paper mentions an issue with duplicate fragments:
...if a system follows the 6lowpan requirements that an overlapping fragment
flush all other fragments, then imperfect duplicate suppression may cause a
receiver to flush fragments that were acknowledged at the data link layer.
I believe there is some confusion here. The intent is not for duplicate fragments to
cause a flush of all previously received fragments. That case is actually not
mentioned explicitly, but the sensible thing to do would be to simply ignore
the duplicate fragments. These you can recognize by their datagram tags
(dgram_tag), your header and the "Frame Length" from the 802.15.4 frame.
The *intent* of the text is error-handling. If there is a non-duplicate fragment
that has an overlap (not a dup) over previously received fragments, this is an
error condition: this implies the sender laid out its IP datagram, sliced it into
fragments in two different ways and is sending you fragments from those two
different ways, using the same datagram_tag. Very confusing.
The normal occurrence is for the sender to cut the IP datagram in only one given way,
give it a datagram_tag and send those fragments out to the receiver. The receiver
will either:
1. receive fragments with no overlap at all (they all cover different ranges in
the original IP datagram), or
2. receive fragments which are duplicates (I guess one could call them "perfect
overlaps", hence the confusion above?)
I'm not sure how likely #2 is, but the format document certainly has no intention
to mess with it.
Is this clearer? Would you suggest some text change to avoid this confusion?
thanks in advance for your comments or clarifications.
-gabriel
----- Original Message ----
From: Philip Levis <[EMAIL PROTECTED]>
To: [email protected]
Sent: Thursday, October 26, 2006 7:21:52 AM
Subject: [6lowpan] 802.15.4 behavior
From: Philip Levis <[EMAIL PROTECTED]>
To: [email protected]
Sent: Thursday, October 26, 2006 7:21:52 AM
Subject: [6lowpan] 802.15.4 behavior
The discussions on this list led Kannan Srinivasan, one of the
students working with me, to submit a paper to HotNets. It was just
accepted. Given that the IETF is in two weeks, we probably won't have
the camera-ready prepared by then, so the link below is for the
submitted version. The title of the paper is "Some Implications of
Low-Power Wireless to IP Routing." It examines the behavior of
802.15.4 using the ChipCon 2420 radio on common sensor node
platforms. The four key observations are:
o Links are predominantly bimodal for short packet bursts.
o Sporadic traffic observes intermediate links, which are due to
SNR variations.
o There are ETX asymmetries, which are larger over longer time
intervals.
o Acknowledgement failures are correlated.
I thought this community might find the paper helpful. It's 6 pages,
so not a long read.
http://csl.stanford.edu/~pal/pubs/hotnets-v-submit.pdf
See you in San Diego...
Phil
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
students working with me, to submit a paper to HotNets. It was just
accepted. Given that the IETF is in two weeks, we probably won't have
the camera-ready prepared by then, so the link below is for the
submitted version. The title of the paper is "Some Implications of
Low-Power Wireless to IP Routing." It examines the behavior of
802.15.4 using the ChipCon 2420 radio on common sensor node
platforms. The four key observations are:
o Links are predominantly bimodal for short packet bursts.
o Sporadic traffic observes intermediate links, which are due to
SNR variations.
o There are ETX asymmetries, which are larger over longer time
intervals.
o Acknowledgement failures are correlated.
I thought this community might find the paper helpful. It's 6 pages,
so not a long read.
http://csl.stanford.edu/~pal/pubs/hotnets-v-submit.pdf
See you in San Diego...
Phil
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
