Re: delayed multihoming/mobility set-up

[Kurt Erik Lindqvist <kurtis@kurtis.pp.se>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>
>>> Uhh, could you clarify how this relates to this subject?  I think
>>> I see a few ways to tie these together, but I'm not sure what your
>>> point is..
>>
>> ( I was a bit fast there, to much mail to read and catch up with)
>>
>> Well the point I was after was your discussion on when a connected
>> session should expect connection survivability. In todays IPv4/IPv6
>> internet, a connection passing over a EGP boundary (and I guess in
>> worst case even inside ASes) will have to take the route
>> cancellation in effect. This means that you will always have to
>> worry about this. So the last you said was :
>>
>>> Note that in low-mobility or site multihoming scenarios you don't
>>> expect the the multihoming to be required *immediately*; the risk
>>> increases in proportion to the time.
>>
>> And I was pointing out that you can't expect it to be immediate in the
>> case above.
>
> No, this does not make sense.
>
> I'm trying to guess what point you're making.  I can see two
> possibilities which neither clearly falls inside your text:
>
>  1) "if a route goes down, how long does it take to be able switch to
> the other connection if the protocols supported transport
> survivability"
>
>  2) "if a route goes down, and comes back up, how long does it take
> until it's fully usable everywhere?"

I was aiming for statement #2 here.


> Both of these are interesting, but not directly related to the
> question I raised, AFAICS.

Maybe I didn't understand your original question correct then.

> The proposal was all about stable configuration.  Instead of setting
> up connection survability immediately when setting up the connection,
> it would only be done for connections that pass certain criteria check
> (e.g. last more than T minutes).  That way, if there is a failure
> inside 0 ... T minutes from the startup of the connection, the
> connection in question will fail.  If not, it'll just switch to the
> another connection transparently, with the possible problems switching
> connections may have.  This is just about optimizing away the
> connection survability for "statistically" short-lived sessions unless
> you really care about that feature.

My point was that in order to determine what a useful "timeout" value 
would be, it has to be longer than the risk of cancellation - depending 
on where in the network you are and what type of sessions we are 
talking about. If T is to low, once you think you have a stable route, 
it might get cancelled. Is this important for end-nodes? Not 
necessarily. If the nodes gets a locator assigned to it - it might.

- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2

iQA/AwUBP8JtiKarNKXTPFCVEQJ8CACghSJau2h4/9MCG7ooLHpHIrhJiOgAni4p
R8L4SATpaBZ968aIp3KFmbuI
=KCPj
-----END PGP SIGNATURE-----