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

On 9-nov-04, at 14:35, Elwyn Davies wrote:

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

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.