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

From: "Kris Pister" <[email-masked]>
Date: Mon, 8 Jan 2007 09:29:58 -0800

>>   (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.
 
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.
 
ksjp
Prof. EECS, UC Berkeley
Founder and CTO, Dust Networks

________________________________

From: Carsten Bormann [mailto:[email-masked]]
Sent: Sun 1/7/2007 12:09 PM
To: gabriel montenegro
Cc: Carsten Bormann; [email-masked]
Subject: Re: SV: [6lowpan] WG last call on Format document

> I'd suggest capturing Phil's issue in the writeup used by the
> chairs to advance the document as per:
>
>    http://www.ietf.org/IESG/content/Doc-Writeup.html
>
> That way we can invite discussion from the IESG on this item.

While it is always a good thing to obtain input from the IESG, I 
don't think delegating this issue to the IESG during document 
submission is the right approach here.

The WG is the domain expert on the kind of network we are discussing 
here.
The WG should come to a conclusion.
The IESG can then check that we followed process and that the 
document fits into the wider IETF picture (which is *not* dominated 
by the relevant considerations here).

<wg-chair hat="off">
   On the reassembly issue, I see two approaches:

   1) keep with the reassembly at destination
   2) open up the sequence such that reassembly-before-forwarding 
becomes an alternative, chosen by the sender.
   3) only allow reassembly before forwarding, i.e. forward only full 
datagrams.

   (As far as I can see, nobody argues for 3, that's why I see *two* 
approaches.)

   The advantage of 2 is more options (Philip has explained why this 
can be a good thing).

   The obvious disadvantage of 2 is more options (i.e., increased 
burden on an implementation).
   With 2, the sender gets to decide whether a forwarder has to 
reassemble before forwarding; the forwarder has to play with that 
decision.
   (Reassembly at the forwarder also means different fragments cannot 
choose different paths; maybe a more theoretical consideration.)
</wg-chair>

I'd like to hear more people taking sides on 1 or 2 before we declare 
consensus.

Gruesse, Carsten

_______________________________________________
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: Mon, 8 Jan 2007 10:18:19 -0800

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

> 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