Re: Comments on draft-ietf-multi6-v4-multihoming-02

On 10-nov-04, at 16:16, <[email protected]> wrote:

> So, are you suggesting that if we want to maintain any multihoming 
> bindings,
> we should rely on application layer keep alives?

Certainly not. What I'm saying is that if applications want to be sure 
a session remains available, they should send keepalives. Then, if the 
session goes away, the app gets to hear about it without much delay.

As far as multihoming goes, we have no business repairing connectivity 
that isn't used. Not only does this use up unnecessary bandwidth, it 
also means unnecessary work as the failures we try to repair may have 
gone away on their own when the communication resumes. There is really 
no upside to being overzealous here.

> So what I meant more was that if we use keep-alives at the multi6
> layer, then perhaps this could be something that the upper layer
> could set the keep-alive behavior.

I could just go on disagreeing, but let me ask you this: assuming a 
decent multihoming solution, under which circumstances would upper 
layers want to do something like that, trying to achieve which 
benefits?

> However, I still don't know if you are suggesting that we use 
> keep-alives at the multi6 layer (in some circumstances) or if you 
> would kick this up to the application layer.

The multihoming layer needs find at least one working address pair (if 
it exists) from the set of all possible address pairs. If we assume 
bidirectional connectivity this isn't all that difficult: send a 
ping-like packet and see if something comes back. But we need to be 
able to use two unidirectional paths rather than one bidirectional one 
in a world where it's possible that routing and ingress filtering get 
in each other's way. Unidirectional reachability testing is a lot 
harder as we need the results of the reachability testing in one 
direction in order to send back the results of reachability testing in 
the other direction.

How is an application ever going to do anything useful in this area, 
even assuming applications that are smart enough (which they won't be)? 
Their interaction with the network is obscured by a transport layer 
which generally hides any unreachability, and the multihoming layer 
which hides address changes. It's like driving a car from inside the 
trunk.