[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-multi6-v4-multihoming-02
On 10-nov-04, at 16:16, <firstname.lastname@example.org> wrote:
So, are you suggesting that if we want to maintain any multihoming
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
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