Just one side note ... I also think that adding a WG item on fragment recovery is needed. That said, we will need to be vigilant here. Mark is right saying that adding too much of flow control there may badly impact the transport layer thus resulting in high delays, waste of energy should the two flow control mechanism get completely out of sync. But that can be discussed once we'll get the work item added if there is a agreement of the WG for doing so.
Mark, we had also a discussion with the Transport AD during the ROLL BOF ... Yes, there is transport work to be done there for LLN (Low power and lossy networks) (not specifically lowpan). Thanks. JP. On 5/20/08 8:18 AM, "Mark Townsley" <[EMAIL PROTECTED]> wrote: > 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
