Extending shim6 to use multiple locator pairs simultaneously

[Scott Leibrand <sleibrand@internap.com>]

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