Hi,
On 5/29/08 4:22 AM, "Pascal Thubert (pthubert)" <[EMAIL PROTECTED]> wrote: > 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? And ... This is not the only issue. Should you need to apply RED mechanisms, the use of multiple path for a single flow becomes challenging since you may end up affecting many more flow than needed. > > 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. > This is one of the issues that I also pointed out when highlighting the shortcomings of combining mesh under and route over. > 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... > JP. > Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
