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

Re: Extending shim6 to use multiple locator pairs simultaneously

Hi Scott,

El 27/03/2006, a las 22:28, Scott Leibrand escribió:
On 03/21/06 at 11:25am -0500, Scott Leibrand <sleibrand@internap.com> wrote:
On 03/21/06 at 10:08am -0600, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote: 


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 base 
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,
though
Yes, definitely. I've read the I-D's, but I should probably re-read them 
with this in mind and see if I can better understand the impact...


Marcelo,

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 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 locator pair. 

Regards, marcelo



Thanks,
Scott