Hi Again Mark: Another aspect of this is ECN. We do not have room for Explicit Congestion Notification in the 6LoWPAN headers. ECN only takes 2 bits in Frame Relay and in IP, though the bits are used differently. I have in mind that the FR version with forward and backward bits is a better fit if it acts upon the fragment flow control, though the FECN could then be mapped into IP ECN.
This is additional work to the fragment recovery and I'm taking great care to present them separate. But it could become an interesting feature in some future as well. Pascal >-----Original Message----- >From: Mark Townsley (townsley) >Sent: mardi 20 mai 2008 17:18 >To: Pascal Thubert (pthubert) >Cc: [email protected] >Subject: Re: [6lowpan] New charter for 6lowpan > >Pascal Thubert (pthubert) wrote: >> Hi again Mark >> >> >>>> - The issue of fragmentation. Applying RFC 4944 over a multihop radio >>>> mesh exposes the network to congestion collapse, as described in >>>> >>>> >> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >> >>>> overy . I think that the WG should dedicate some bandwitdth to >>>> >> provide >> >>>> additional functions that would improve the LoWPAN operation WRT flow >>>> control and recovery of fragments. >>>> >>>> >>> Fragmentation, OK, but why is flow control a network layer issue rather >>> than a transport layer issue? >>> >> >> [Pascal] I'm talking about flow control on the fragments themselves; >> this is either a LLC (the likes of 802.2 or LAPB) or a shim layer above >> LLC problem (that would be us). The 802.15.4 MAC/PHY was not design to >> cope with IPv6 MTU and when the IPv6 stack sends a NLPDU of 1280 bytes >> minimum, it causes a burst of fragments that should be paced and >> windowed. I suggest we do it in 6LoWPAN and handle the consequences of >> our own fragmentation rather than rely on a LLC mechanism that might not >> be there or adapted. >> >OK, that makes sense. Of course, if the higher layer transports consider >this fragmented packet lost and retransmit in the mean time we will end >up thrashing. We need to be very wary of the higher-layer transport >affects. And, of course this isn't the first time I've thought we might >need ot spin up a transport-area lowpan WG similar to what we did with >ROLL. But, sometimes its hard enough to keep 2 working groups working >and making progress, much less 3. > >- Mark >> Pascal >> >> >> _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
