Hi Mark: It would be great to get some help from transport area but forking a WG could be overkill for the task at hand. We know that we'll get less than 32 fragments, so we can acknowledge the received ones with a simple DWORD bitmap, and we do not really need a complex sliding window but rather a simple number of outstanding fragments that we can play with for flow control.
For those who doubt that the feature is really important, I have compiled some references and history on fragments in the Internet in my draft; it appears that a multihop Low Power & Lossy mesh can be worse a situation than many we've seen in the past and getting dozens of fragments just do not help. This is why I strongly suggest that we add fragment control and recovery to the charter. 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
