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

[<john.loughney@nokia.com>]

Iljitsch,


> > A problem with all of these schemes is that they have no inherent means for
> > informing the multihomed site of a failed path where the failure is not in a
> > link directly connected to the link.  A major failure in the provider
> > network or an upstream transit provider can result in outgoing traffic 
> > being blackholed even though incoming traffic is being rerouted via the
> > alternative path.
> 
> We have discussed this extensively in the design team.
> 
> The obvious solution is to send keepalives all the time. This is what 
> SCTP does and it's very wasteful in bandwidth, and it may have 
> substantial unpleasant side effects. For instance, if I close the lid 
> on my laptop for a minute, I don't want the other side to declare me 
> disconnected and break my SSH session.

Closing your lid shouldn't change anything.  Putting your laptop in a sleep-mode
probably will disconnect your SSH session, and I am sure that there are
some providers (or companies) that would like this to happen, in VPN-type
situations.

> The non-obvious solution is to suppress keepalives when it's clear that 
> they aren't needed. This can happen in two cases:
> 
> 1. When there is no traffic in either direction
> 2. When there is traffic in both directions
> 
> Only when there is traffic in only one direction there MAY be a failure 
> condition, so keepalives are in order to make sure. This should work 
> very well except that failures may now only be detected by one end. For 
> instance, when A and B communicate and there is only reachability from 
> A to B but not the other way around, A won't detect the failure if B is 
> sending data, because A is both receiving B's data and sending out 
> ACKs. However, B will see data going out but nothing coming back so B 
> notices the potential failure and can trigger reachability testing.

I agree that supressing keep alives when traffic is flowing is reasonable.
Supressing when no traffic is flowing is debatable.  If you are doing
site multihoming and want to make sure you maintain site connectivity,
you might want to have keep-alives.  

I'd propose that sending keep-alives might be a tunable setting, and the timing
of sending keep-alives could be set according to policy (host or site).

John