Re: Extending shim6 to use multiple locator pairs simultaneously

[Scott Leibrand <sleibrand@internap.com>]

On 03/21/06 at 7:02pm +0100, Iljitsch van Beijnum <iljitsch@muada.com> wrote:

> On 21-mrt-2006, at 17:25, Scott Leibrand wrote:
>
> > 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've actually worked on some stuff where we load balanced a bunch of
> traffic over several TCP sessions towards different destinations
> (where it didn't matter which part of the aggregate traffic ended up
> where), and the results were interesting. When you get the hang of
> it, it works pretty well, though. The key issue is that you feed data
> to the right session/path. If you don't, you run the risk of being
> limited by the slowest one, and have performance that's even worse
> than not bonding the paths.
>
> When I think about this, this may not be all that easy if only the
> sending side knows about what we're doing. You probably need to use
> selective acknowledgments and you may still trigger fast retransmit
> often and take TCP processing at the receiver off of the fast path.

I'd certainly want to make SACK a prerequisite for starting up multipath,
and IMO the multipath sender would definitely need to have his duplicate
acknowledgement processing modified in order to only trigger fast
retransmit when appropriate.

I'm not sure what you mean by "take TCP processing at the receiver off of
the fast path": can you elaborate on that?

> And you'd have to be really careful to make sure that the unmodified
> side doesn't see confusing RTT estimates.

True.  I would think that in order to minimize that for the unmodified
(non-multipath) side, you'd want to use a single locator pair (probably
the one the unmodified side is using) for sending all acks, and only use
the second pair for transmitting multipath data.  That would ensure a
single round-trip path for data from the unmodified (non-multipath) sender
and acks back from the modified (multipath) receiver.

-Scott