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

From: <[email-masked]>
Date: Wed, 10 Nov 2004 16:33:49 +0200

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 10 Nov 2004 16:06:44 +0100

On 10-nov-04, at 15:33, <[email-masked]> wrote:

>> For instance, if I close the lid

> 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

I'm sure there are, but I'm just as sure there are also people like me 
who prefer the session to remain up so there is no need to reconnect 
after waking up. FYI: SSH disconnects after several hours by default, I 
think because of an automatic 2-hourly TCP keepalive. I managed to make 
it such that sessions would remain up overnight but that doesn't work 
anymore since one upgrade or another.

> you might want to have keep-alives.

No, this is something that has the potential to be harmful. If 
transports or applications feel they need to keep sessions alive 
explicitly, they are free to do so and multihoming mechanisms will make 
sure that rehoming happens if such a keepalive doesn't make it. But if 
multihoming does the keeping alive, there is no way for transports or 
apps to be network-quiet if they want to be.

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

Disagree vehemently. Polling is bad, interrupts are good.

---

From: Geoff Huston <[email-masked]>
Date: Thu, 11 Nov 2004 02:14:33 +1100

>of sending keep-alives could be set according to policy (host or site).

If you are talking about what makes multi-homing trigger a location change, 
then the observation as I see it is that the existing amount of information 
passed vertically in the protocol stack is inadequate. Wether its 
keepalives, transport level timeouts, ICMP messages or any other means of 
detection of 'failure' you need to be able to pass this information to the 
point where a multi-homing homing change can be undertaken. I'd agree with 
John's perspective that it is not easy to pre-determine the settings that 
relate to failure detection, and a reasonable response is to make such 
settings tunable.

   Geoff