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

[<john.loughney@nokia.com>]

Ilijitsch,

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

Got it.
 
> As far as multihoming goes, we have no business repairing onnectivity 
> 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.

Agree.  
 
> > 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?

I'm not wedded to the use of keep-alives; to back it up a level,
if there are keep alives at the multi6 level, it would be nice if
the use of the keep-alive could be tunable by the ULP.  If we 
toss out keep-alives at the multi6 level, I won't lose sleep at it.
 
> > 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.

Ack.
 
> 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.

At the same time, how does the multi6 layer understand what kind of 
connectivity the application needs?  With wireless links, its really 
easy to get intermittent connectivity. How do we classify when the
connectivity is too poor to be useful - the application should be able
to determine this and ask for using a different address pair.

John