RE: Extending shim6 to use multiple locator pairs simultaneously

[Scott Leibrand <sleibrand@internap.com>]

Yeah.  The main motivation on my part for doing an RFC would be that if
I'm a multihomed user seeking to benefit from this, I would want the
server(s) I'm downloading from to support it as well, so they could send
me traffic over both my links.  If I just implement it on my own host, I
would only be able to upload with both links, not download.

-Scott

On 03/20/06 at 11:31pm -0800, Tony Li <tli@tropos.com> wrote:

>
> Scott,
>
> I think that would indeed work.  Further, as that is entirely contained
> within a single implementation and doesn't require any protocol changes,
> I don't think it requires an RFC.  Not that one wouldn't be welcome, of
> course.
>
> Regards,
> Tony
>
>
> > -----Original Message-----
> > From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On
> > Behalf Of Scott Leibrand
> > Sent: Monday, March 20, 2006 8:51 PM
> > To: shim6@psg.com
> > Subject: Extending shim6 to use multiple locator pairs simultaneously
> >
> > I recently had an idea that I thought I should bring up here (then
> > possibly write up as an I-D):
> >
> > 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.
> >
> > 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.
> > 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?  If
> > not, should I start writing up an Internet-Draft on it?  I
> > brought this up
> > in the shim6 Jabber room today, and was told that this might
> > be logical
> > followup work to the base shim6 spec.  Do others agree with that
> > assessment?  (This is my first IETF, so if anyone has any other newbie
> > advice, feel free to speak up.)
> >
> > If I'm not missing anything big, and this is indeed workable,
> > I think this
> > could be a big enough feature to help push shim6 adoption onto a wide
> > installed base.
> >
> > Thanks,
> > Scott
> >
> >
>
>
>
>