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

Hi Iljitsch,

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

Right, so assuming a default behavior here is probably wrong.
 
> > 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.
> 
> 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.

So, are you suggesting that if we want to maintain any multihoming bindings,
we should rely on application layer keep alives?  I guess that is another
possibility, especially if we consider 'testing' connections at session
startup, that then might be sufficient.
 
> > 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 your earlier mail, it wasn't clear, let me just quote you:

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

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

John