Subject: Re: [6lowpan] 802.15.4 behavior

From: gabriel montenegro <[email-masked]>
Date: Thu, 26 Oct 2006 14:53:07 -0700 (PDT)

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.

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-masked]>
To: [email-masked]
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-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: Philip Levis <[email-masked]>
Date: Thu, 26 Oct 2006 17:28:13 -0700

> I'm not sure how likely #2 is, but the format document certainly  

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  

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

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 26 Oct 2006 22:59:20 -0600

Gabriel,
  I'm wondering if the entire text around this should be eliminated and
should the text about buffer handling?  These are implementation details
and might instead be left as an exercise for the implementer.

Maybe the text around overlapping fragments should read:

If an overlapping fragment is received and that fragment is not a
duplicate, this should be considered an error.

The implementation can determine what to do with the current fragment or
the previously received fragments.

	geoff