Re: Extending shim6 to use multiple locator pairs simultaneously

[Scott Leibrand <sleibrand@internap.com>]

On 03/21/06 at 10:08am -0600, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:

> This is an interesting extension of shim6 indeed...

Thanks.

> some comments below...

Ditto.

> El 20/03/2006, a las 22:51, Scott Leibrand escribió:
>
> > Say you have two shim6-capable hosts, and at least one of them has two
> > transit connections (say DSL + Cable) with two corresponding locators.
> > Now say the two hosts establish a connection, start sending traffic,
> > and establish shim6 state.  Now say that the multihomed host has lots
> > of data to send, and is maxing out the default (ULID-ULID) path.  Now
> > say that he has implemented some shim6 extensions that allow him to
> > simultaneously send packets with the shim6 context tag over the second
> > locator pair while continuing to send packets over the ULID-ULID pair.
> > These extensions also include modifications to his TCP stack such that
> > he can independently track the congestion windows (and run the TCP
> > congestion avoidance algorithm) for each locator pair.
>
> But if you need to change both the shim and TCP perhaps this is too
> many changes...

Perhaps.  But as others have pointed out privately, TCP and IP are usually
implemented together as TCP/IP.  So for implementors this would probably
be less of a problem than for the IETF, where IP and TCP are under the
purview of different WG's (and even Areas?).  Perhaps we could specify a
shim6-only implementation, and simply point out that implementors may make
further optimizations to TCP to improve performance if they wish...

> First i would like to understand what would be the effect of using
> multiple locator pairs  in order to use multiple parallel paths without
> modifying TCP. I guess that this would be nasty for TCP, but i would
> like to make quantify the results of such approach. I mean, having the
> shim to support this without requiring modifications to TCP would make
> this is much more attractive i guess

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.

> > This would allow the sending host to fully utilize the available
> > bandwidth on both his links for a single TCP session, which otherwise
> > would be impossible (without bonding the two links with some sort of
> > per-packet load balancing, which you can do for outbound, but not for
> > inbound with two different providers).  It would require some
> > modifications to the sending host in order to keep track of
> > everything, but the receiving host need only do ordinary shim6 and ack
> > packets as they came in.
>
> i guess that we need to understand the impact of this in the shim6 base
> protocol and the failure detection mechanism, since both of them are
> currently designed to use a single locator pair to exchange traffic.
> I don't think that there would be much trouble with supporting this,
> though

Yes, definitely.  I've read the I-D's, but I should probably re-read them
with this in mind and see if I can better understand the impact...

> >  Since the shim would be in place, the recipient's TCP stack would be
> > completely unaware of the fact that his packets are coming over two
> > different paths.
> >
> > Can anyone think of any show-stopper reasons why this wouldn't work?
>
> I would like to understand how badly this behave if we use it without
> updating TCP

Ok.  Let me do some quick modeling and confirm that my mental model above
seems to be correct.  I'll also have to consider whether out-of-order
packet arrival will be much of a problem...

Thanks,
Scott