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 PROTECTED] Sent: Mon 1/8/2007 10:18 AM To: Kris Pister Cc: [email protected] 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 protected] https://www1.ietf.org/mailman/listinfo/6lowpan
