Subject: Re: [6lowpan] 802.15.4 behavior

From: gabriel montenegro <[email-masked]>
Date: Fri, 3 Nov 2006 12:55:40 -0800 (PST)

It seemed like there was a very minor problem that was reported in this respect,
and that very minor issue would be taken care of by Phil's suggestion of
slight rewording:

"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..."

So I have taken that suggestion, which basically implies adding the
part about "and differs in either the size or datagram_offset of  
the overlapped fragment" to the existing text.

-gabriel

----- Original Message ----
From: Geoff Mulligan <[email-masked]>
To: gabriel montenegro <[email-masked]>
Cc: Philip Levis <[email-masked]>; [email-masked]
Sent: Thursday, October 26, 2006 9:59:20 PM
Subject: Re: [6lowpan] 802.15.4 behavior

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

On Thu, 2006-10-26 at 14:53 -0700, 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.
>  
> 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

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