Hi Jonathan: Resending, I forgot to change the title
>The second issue is whether or not we constrain forwarding fragments of >a given datagram to a single path. This is where mesh-under and >route-over diverge. But to me, there are a lot of advantages to >constraining delivery of a datagram to a single path. Hop-by-hop >recovery can ensure in-order delivery. Hop-by-hop congestion control >becomes much more meaningful. It's unclear to me what end-to-end >congestion notification means in a mesh-under setting. We can also take >advantage of link optimizations to increase throughput and decrease >latency. And, as mentioned before, reduces header overhead by not >needing addressing information in subsequent fragments. [Pascal] This is a critical design point. We had long talks with Rick Enns on this. A classical Internet behavior when doing multipath load balancing is to attach a flow on a given path. The reasoning is that if TCP flows are balanced over multiple paths, then all the flows experience the speed of the slowest path. This is due to the reaction of TCP flow control to packets being delayed and arriving out of order. So it's generally better to assign intelligently (based on feed back) or blindly (round robin and hash) the flows to the paths and try your luck. Is this the case here too? Another angle on this is that if we allow fragments over multiple paths, the reassembly process still forces all the paths to converge at the intermediate point where reassembly occurs. Say we have a destination outside of the LoWPAN. We could theoretically have to paths from a mote to that destination over 2 different sinks (default gateways). But that's not possible for fragments because one of the gateways needs all the fragments to reassemble the packet. Finally if we define ECN in 6LowPAN, for instance in the mesh header where it would make sense, then there's always a way for the layer below to pass its congestion information so that the 6LoWPAN mesh handler sets the flag in the mesh header. Many questions... Pascal >-----Original Message----- >From: Jonathan Hui [mailto:[EMAIL PROTECTED] >Sent: mardi 27 mai 2008 18:27 >To: Pascal Thubert (pthubert) >Cc: Philip Levis; Jean Philippe Vasseur (jvasseur); Mark Townsley (townsley); [email protected] >Subject: Re: [6lowpan] New charter for 6lowpan > > >Hi Pascal, I see a few underlying issues in this discussion. > >First is whether or not route-over implies complete reassembly at >every hop. In my view, it doesn't. A node could simply cache the >datagram tag when the first fragment arrives and forward the >subsequent fragments accordingly. Note that this also saves header >overhead because the mesh header doesn't have to be included in every >fragment. When forwarding between different links, reassembly has to >happen anyway. > >The second issue is whether or not we constrain forwarding fragments >of a given datagram to a single path. This is where mesh-under and >route-over diverge. But to me, there are a lot of advantages to >constraining delivery of a datagram to a single path. Hop-by-hop >recovery can ensure in-order delivery. Hop-by-hop congestion control >becomes much more meaningful. It's unclear to me what end-to-end >congestion notification means in a mesh-under setting. We can also >take advantage of link optimizations to increase throughput and >decrease latency. And, as mentioned before, reduces header overhead by >not needing addressing information in subsequent fragments. > >The third issue is whether or not end-to-end mechanisms should be used >for recovery and congestion control. I think we agree that hop-by-hop >mechanisms are required regardless. They increase reliability and can >provide effective congestion control and mitigation. To me, hop-by-hop >mechanisms are generally much more effective than end-to-end ones >because they react to local conditions and can quickly provide back- >pressure all the way to the source. From a reliability standpoint, >we've seen solutions deliver >99.9% without end-to-end recovery. So >one question is how much more reliability do we really need? and does >it justify the added energy overhead and code size? > >-- >Jonathan Hui > > > >On May 26, 2008, at 7:18 AM, Pascal Thubert (pthubert) wrote: > >> Hi Phil: >> >> We do agree on the problem. >> >> Per-hop reassembly, though, comes at the expense of that traffic >> fluidity that was so desirable to the ATM designers. In other words, >> because per-hop reassembly forces each intermediate node to store and >> forward a full packet, it is augmenting the latency of the flow and >> the >> memory requirements on the forwarding nodes on the way. >> >> This is why I had in mind to couple a few per-hop recovery with a more >> solid end-to-end recovery and flow control mechanism between the >> LoWPAN >> endpoints. >> >> Now I wonder what this discussion becomes in route over v.s. mesh >> under. >> In route over, it seems that the forwarding node terminates a link >> so it >> has to reassemble before it forwards on a different link that might or >> might not be a LoWPAN; so maybe we end up doing the same thing in that >> case. >> >> Jonathan, what do you think? >> >> Pascal >> >>> -----Original Message----- >>> From: Philip Levis [mailto:[EMAIL PROTECTED] >>> Sent: vendredi 23 mai 2008 19:46 >>> To: Pascal Thubert (pthubert) >>> Cc: Jean Philippe Vasseur (jvasseur); Mark Townsley (townsley); >> [email protected] >>> Subject: Re: [6lowpan] New charter for 6lowpan >>> >>> >>> On May 23, 2008, at 3:50 AM, Pascal Thubert (pthubert) wrote: >>> >>>> 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. >>> >>> This gets back to the point I brought up December 14, 2006. In lossy >>> networks, end-to-end fragmentation and assembly is a real problem. It >>> makes much more sense to do per-hop fragmentation and assembly. In >>> the >>> former, the number of retransmitted fragments is exponential in the >>> number of hops; in the latter, it is linear. >>> >>> Phil _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
