Scott,This is an interesting idea. I think that the hard parts about this fall squarely in the transport protocol, and that the shim might not need to change at all (You might just need to have the transport tell the shim to do forked contexts, and that way the shim will automatically verify that the two paths are working.)
Scott Leibrand wrote:
Ok, that's certainly worth study. In some mental modeling I've done so far, the biggest problem I see in not using TCP congestion control on each locator pair is in deciding how much traffic to send over each link. I suppose you could use both links equally, which would allow you to use (# of links) * (the bandwidth of the slower link) rather than the sum of the bandwidths of all the links. IOW, as soon as one link experiences congestion, the sending rate would be halved over all links.
I suspect there are other issues than congestion control.For instance, you will have some skew between the different paths, causing packets to arrive at a different order than they were sent. This will cause the receiving TCP to send duplicate ACKs, and after the sender has received 3 duplicate ACKs, it will do a fast retransmit. Those types of algorithms would need to be make robust against packets arriving out of order.
In terms of thinking about this, it might make sense to start with SCTP, since SCTP already supports tracking congestion information for each path. Then you can ask yourself what would be needed if both paths were used as the same time. Once we know what to do, then applying it to TCP would be conceptually simple (even though it might be hard in practice.) Note that SCTP only uses one path at a time, and only switches after detecting a failure. So AFAIK the SCTP folks didn't explore what would happen is both paths are used concurrently.
Erik