Hi Pascal, Just a word of cautious though. It is not the number of needed bits that matters here but what you do with them. ECN is clearly a fairly big WG item (Look at the history of IP in that area or even FR by the way where several pretty sophisticated mechanisms had been designed to handle this - or trivial task). I would personally suggest to not add this to the WG charter for the moment.
Thanks. JP. On 5/20/08 9:01 AM, "Pascal Thubert (pthubert)" <[EMAIL PROTECTED]> wrote: > 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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
