Subject: RE: SV: [6lowpan] WG last call on Format document

From: "Kris Pister" <[email-masked]>
Date: Mon, 8 Jan 2007 11:05:57 -0800

I agree with you that rapid route fail-over is a perfectly viable alternative (and probably provably superior in many cases) to next-hop diversity.  But whichever you use, it makes single-hop reassembly of packets difficult.
 
That's great news about tinyOS 2 reliability.
 
ksjp

________________________________

From: Philip Levis [mailto:[email-masked]]
Sent: Mon 1/8/2007 10:18 AM
To: Kris Pister
Cc: [email-masked]
Subject: Re: SV: [6lowpan] WG last call on Format document

On Jan 8, 2007, at 9:29 AM, Kris Pister wrote:

>>>   (Reassembly at the forwarder also means different fragments cannot
>>> choose different paths; maybe a more theoretical consideration.)
>
> This is absolutely not a theoretical consideration.  We call these 
> networks and headers "mesh" for a reason: there's an intuitive 
> sense that multiple routes provide better performance.  This 
> intuition is now supported by substantial empirical evidence (in 
> addition to theory and simulation): implementations that say "mesh" 
> and deliver quasi-static trees are not reliable.  Zigbee did a 
> disservice to the community by defining "mesh" to be "multi-hop" in 
> the 2003 standard.

Right -- the big question is the rate at which the routes can adapt. 
Multiple routes do not in and of themselves necessarily provide 
better robustness; unlike in the wired case, nodes are physically 
correlated and so can fail together. I'm personally not convinced 
that one of fine-grained packet next-hop diversity or rapid route 
failover is inherently superior to the other.

I'd argue that the lack of reliability we've seen in quasi-static 
trees has been due to a mismatch between route adaptation and data 
traffic, with no backpressure. That is, if your route changes at most 
every 8 seconds, you can buffer 10 packets, the sender drops on layer 
2 acknowledgment, and there is no way to slow down your reception 
rate of 5 packets per second, then a route failure will lead to 
packet loss. If you look at the current layer in TinyOS 2.0, for 
example, it delivers two nines, with the packet losses being due to 
false positives on layer 2 acks. I know that this is well below what 
Dust can deliver, but to be fair, it uses an ad-hoc rather than 
centralized approach and has been written by a few grad students 
spread across the country rather than an experienced development team.

> Phil makes a good case for single-hop reassembly in his 12/14 
> treatise, and his arguments are valid from a tinyOS and/or Zigbee 
> perspective.  F, X, and L will be large, and if link-level 
> acknowledgements are not used, then the energy cost of multi-hop 
> reassembly will be prohibitive.  Indeed, the probability of success 
> decreases so rapidly with increasing F and X that the question 
> "does it work at all?" takes precedence over "is it energy 
> efficient?".
>
> There are two international sensor networking standards in the 
> works right now (HART and SP100) which will both include mesh 
> routing and link-level acknowledgements.  Both will support energy-
> efficient fragmentation and end-to-end reassembly with large F, X, 
> and L.  Both are based on existing products built on top of 802.15.4.
>
> I think that option 2 below is probably still fine.  Giving people 
> this level of flexibility is still useful as we explore this 
> comparatively young space, but let's do it informed by the pre-
> existing solutions to similar problems.
>

Does saying headers can appear in either order break from IPv6?

Phil

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