RE: Extending shim6 to use multiple locator pairs simultaneously

["Tony Li" <tli@tropos.com>]

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
> 
>