Hi JP: I see your concern.
I'd argue that ECN is now pretty well defined now in RFC 3168, and that the basic operation is pretty simple: emulate a packet loss in RED but save the packet. So the real problem is not ECN itself but what RED becomes in a LowPAN forwarding node. And that is something that the node will have to define whether it does ECN or RED. If we do not have ECN then the LowPAN forwarding nodes will have to destroy frames which might be fragments. Considering the cost of energy and bandwidth to getting the frame up to that forwarding node, the latency introduced by transport layer time out, and the risk of congestion collapse introduced by resending the whole segment, I'd suggest that ECN is actually a good idea. Please have a careful look at: http://www.ietf.org/internet-drafts/draft-thubert-6lowpan-simple-fragmen t-recovery-01.txt that I just update with additions on flow control operation and ECN-echo support. Pascal >-----Original Message----- >From: Jean Philippe Vasseur (jvasseur) >Sent: jeudi 22 mai 2008 16:31 >To: Pascal Thubert (pthubert); Mark Townsley (townsley) >Cc: [email protected] >Subject: Re: [6lowpan] New charter for 6lowpan > >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
