Hi: JP: >> Question: could you explain the rationale for leaving out the fragmentation >> recovery item?
Geoff: >I am less certain that there is consensus that fragment recovery is a >necessary working group item at this point. So I will ask the WG. Considering that 6LoWPAN packets can be as large as 2K bytes and that a 802.15.4 frame with security will carry in the order of 80 bytes of effective payload, a packet might be fragmented into about 25 fragments at the 6LoWPAN shim layer. This level of fragmentation is much higher than that traditionally experienced over the Internet with IPv4 fragments. At the same time, the use of radios increases the probability of transmission loss and Mesh-Under techniques compound that risk over multiple hops. Past experience with fragmentation has shown that missassociated or lost fragments can lead to poor network behaviour and, eventually, trouble at application layer. Enlighteneing reading on that subject is found in http://tools.ietf.org/html/draft-mathis-frag-harmful. That experience led to the definition of the Path MTU discovery protocol that avoids fragmentation over the Internet. An end-to-end fragment recovery mechanism can be a good complement to a hop-by-hop MAC level recovery with a limited number of retries. Additional flow control and Explicit Congestion Notification would help prevent congestion collapse. We have enough experience at the IETF to know that these mechanisms are required and design them properly. Pascal >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Mulligan >Sent: vendredi 13 juin 2008 19:25 >To: Jean Philippe Vasseur (jvasseur) >Cc: 6lowpan >Subject: Re: [6lowpan] New new charter text > >JP, > As I said previously, when Carsten, Mark and I reviewed the >comments/messages on the list it was clear that ND, Architecture, and >Security were priority items along with dealing with enhancements to >compression of non link local addresses and that there was clear support >to take these on within the working group. And now also the Use Cases >draft. > >I am less certain that there is consensus that fragment recovery is a >necessary working group item at this point. So I will ask the WG. > >As to your question about the Arch doc, I'm not sure that I understand >the question or the timing? The text for this hasn't changed for >months. It seems that there are members of the WG that want to see the >architectural description that includes both a mesh under solution and a >route over. How would you propose that we determine if there is a need >for both? > >geoff > >On Fri, 2008-06-13 at 18:01 +0200, JP Vasseur wrote: >> Hi Geoff, >> >> Thanks for sending out the new revision. One question, one comment. >> >> Question: could you explain the rationale for leaving out the fragmentation >> recovery item? >> >> Comment: >> >> "3. Produce "6LoWPAN Architecture" to describe the design and >> implementation of 6LoWPAN networks. This document will cover the >> concepts of "Mesh Under" and "Route Over", 802.15.4 design issues such >> as operation with sleeping nodes, network components (both battery- >> and line-powered), addressing, and IPv4/IPv6 network connections. >> As a spin-off from that document, "6LoWPAN Routing Requirements" will >> describe 6LoWPAN-specific requirements on routing protocols used in >> 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. >> Both documents will be informational." >> >> I do not understand the rationale here: I think that we should first >> determine whether we both need a mesh-under *and* a route-over approach. You >> know my opinion: we have numerous examples in the past of such approaches >> that ALL failed for obvious technical reasons but this is my technical >> opinion. As far as 6lowpan is concerned, shouldn't we first have a >> discussion to get a consensus there ? *If* it turns out that both are >> needed, then add an introductory section in the architecture document >> pointing to the requirement document(s). >> >> Thus I would rather suggest not to list this as a WG item but to leave it >> out for the moment and continue to have the discussion until we have a >> consensus. Then at that point we could decide what to do. On the other hand, >> having a separate documents listing the 6LoWPAN specific routing >> requirements, owned by the 6lowpan WG and reviewed by ROLL would make a lot >> of sense. >> >> Thoughts ? >> >> Thanks. >> >> JP. >> >> >> >> On 6/13/08 3:59 PM, "Geoff Mulligan" <[EMAIL PROTECTED]> wrote: >> >> > With the input from the authors we've put the "Use Cases" back into the >> > text for the charter for the working group with a delivery date of Dec >> > 08. >> > >> > Attached is the NEW new charter text. >> > >> > geoff >> > >> > _______________________________________________ >> > 6lowpan mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/6lowpan > >_______________________________________________ >6lowpan mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
