[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Extending shim6 to use multiple locator pairs simultaneously



Hi Scott,

This is an interesting extension of shim6 indeed...

some comments below...
El 20/03/2006, a las 22:51, Scott Leibrand escribió:

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.


But if you need to change both the shim and TCP perhaps this is too many changes...

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 wihtout requiring modifications to TCP would make this is much more attractive i guess

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

 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

regards, marcelo


  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