[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Extending shim6 to use multiple locator pairs simultaneously
El 27/03/2006, a las 22:28, Scott Leibrand escribió:
On 03/21/06 at 11:25am -0500, Scott Leibrand <email@example.com>
On 03/21/06 at 10:08am -0600, marcelo bagnulo braun
El 20/03/2006, a las 22:51, Scott Leibrand escribió:
i guess that we need to understand the impact of this in the shim6
protocol and the failure detection mechanism, 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,
Yes, definitely. I've read the I-D's, but I should probably re-read
with this in mind and see if I can better understand the impact...
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
but you'd likely know better than I if there are any other issues to
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 loccator
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.
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.
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, 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