On Oct 26, 2006, at 2:53 PM, gabriel montenegro wrote:
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:
...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.
The text refers to 2. Our reading of "overlap" included the
degenerate case of what you call perfect overlap. Does that seem
reasonable?
As an aside, I assumed that besides error conditions, the draft was
also considering problems such as encountered by TCP stacks (IIRC,
some stacks discard the new payload, others use the new payload).
While CRCs would likely makes this moot, it *is* an error condition
and so you might as well preclude it.
Is this clearer? Would you suggest some text change to avoid this
confusion?
I think just saying what you want (I think?) to say would be best,
and distinguish the two cases.
"If a link fragment is received that overlaps another fragment as
identified above and differs in either the size or datagram_offset of
the overlapped fragment..."
Apologies for the terseness: it's a product of preparing the next
release of TinyOS and so being a bit overwhelmed.
See you in San Diego...
Phil
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
