[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Extending shim6 to use multiple locator pairs simultaneously
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.