>> (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 PROTECTED] Sent: Sun 1/7/2007 12:09 PM To: gabriel montenegro Cc: Carsten Bormann; [email protected] 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 protected] https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
