[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 15:33, <john.loughney@nokia.com> wrote:

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.

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.

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.

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.