Re: Extending shim6 to use multiple locator pairs simultaneously

[Scott Leibrand <sleibrand@internap.com>]

On 03/28/06 at 9:41am +0300, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:

> El 27/03/2006, a las 22:28, Scott Leibrand escribió:
>
> > Would the impact on the failure detection mechanism be eliminated by
> > having TCP initiate a new forked context for each additional path it
> > wanted to use?
>
> yes this seems a clever idea indeed
>
> >   That way, each context would consider only a single path as "active"
> > at any one time.  Upon my initial re-read of
> > draft-ietf-shim6-reach-detect-01.txt, that seems it would be
> > sufficient, but you'd likely know better than I if there are any other
> > issues to worry about...
>
> well, forked contexts behave like two separate contexts.
> This basically means that there is not a conscience that they are both
> being used for sending data for the same communication. This means for
> instance that both contexts may end-up using the same locator pair
> after a failure i guess (I am not sure how would a forked context would
> rehome a communication after a failure in the selected locator pair has
> been detected, but i guess that the default behaviour would be to
> explore and find an alternative path, in which case, two different
> forked context may end up using the same locator pair). this basically
> means that we would end up running the failure detection protocol over
> the same locator pair, for two forked context that are actually being
> used for the same communication, which seems to be at least suboptimal.
> In addition, after a failure, the desired behaviour would probably be
> that the different forked contexts are rehomed to different locator
> pairs in order to still benefit from multipath. However, since the shim
> has no conscience that the multipath is being used, it won't be able to
> actually take this into account when selecting the new locator pairs.

Yes, I agree that in a failure scenario you have the possibility of
collapsing both contexts onto the same path.  Since such a situation
provides little benefit, it would be in the ULP's interest to be notified
of a failure & rehoming event, so that it could stop using the forked
context or possibly tell the shim to try to find another locator pair that
works and isn't already in use.

> Bottom line is, that context forking is a tool to be used by ulp that
> want to have control of the locators. So, because of that, ULP need to
> be more involved in the decision and this does not work so
> automatically, especially when decision such as selecting alternative
> locators are required.

Yes, I agree.  The shim is responsible for restoring reachability, and the
ULP is responsible for telling the shim if it wants anything done
differently to meet the ULP's specific needs.  As long as the API supports
that, we're good.

> However, this may well be a starting point for this and optimizations
> can be worked out for this case. For instance, to include this type of
> considerations in the locator selection process,

I would envision the ULP telling the shim about its locator pair
preferences for each context, and the shim simply taking that at face
value (and not try to infer anything about the "best" locator pair from
the other forked context).

> or as Iljitsch suggested a long time ago, to allow that a single
> keepalive/probe message is used to test all the contexts that are using
> the same locator pair.

That might be appropriate, but it would seem that you'd want to keep the
contexts conceptually separate, and just let implementors take advantage
of overlap as long as it exists.  This reminds me of shared memory, where
multiple processes can have read access to the same chunk of code in
memory, but if one of them tries to write to it, the OS makes a new copy
to allow that process to have its own copy to play with.

-Scott