Hi Jonathan: >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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
