Subject: [tcpm] host behaviour when connectivity is lost

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 9 Nov 2012 06:01:31 +0100 (CET)

Hello.

I don't know if this is appropriate for this WG, please tell me if it's 
not.

A while ago, I pitched an idea in the linux-netdev mailing list, regarding 
how a connection manager might hint the TCP stack of the host, to do 
things depending on network conditions.

The post is here: <http://www.spinics.net/lists/netdev/msg213615.html>

Would what I am suggesting be appropriate to discuss here and perhaps even 
create a document giving guidance to TCP implementors about APIs that 
might be helpful, and how they should behave? I believe the problem I'm 
describing is real and it affects users all the time.

Here is the text:

------------------------------------

I'm a network engineer, as in I work primarily with IP routing. Ever since 
I started running Linux back in the mid 90ties I've had a love/hate 
relationship with how Linux handles disappearing network connectivity or 
IP addresses.

In my mind there are two ways to handle outage:

1. When a network connection (physical interface) goes down, keep 
everything as it is, it might come back up again shortly and then we can 
continue as if basically nothing happened. TCP was designed for this 
considering timeouts can be in hours.

2. When a network connection (physical interface) goes down, wait a few 
seconds, give up, reset all connectivity related to that connection, 
basically give up.

Now to my question for the netdev people:

Is there functionality in the kernel for a connection manager to easily 
accomplish 2, in that when it tries to deconfigure the IP address on the 
interface to also kill all TCP connections terminated at that IP? On my 
laptop, I regularily have to kill my ssh client after suspend/resume 
cycle, because it's been down for quite a while, and the ssh client 
doesn't know the TCP connection is now not functional anymore (TCP session 
is still up and retransmit won't happen for a while, so the TCP RST from 
the server (I use keepalives within SSH) isn't seen for a long time).

Without knowing what's in place right now, I see some behaviours that I'd 
like to have:

After resume (or otherwise network connectivity re-established), 
connection manager should be able to tell the kernel to:

a) kill all TCP/UDP/other sessions existing which doesn't currently have 
an active IP address on the machine. This is for the sake of local 
clients. b) the TCP/SCTP sessions that *do* have an IP, should have their 
retransmit timers "reset", so that whatever needs to be sent, should be 
sent immediately (or shortly, within a few seconds). c) tell the kernel to 
kill all TCP sessions bound to a certain IP, because the connection 
manager is going to remove it shortly. Send TCP RSTs or whatever and close 
the TCP session, so both ends know that network connectivity is going 
down.

This would mean that if I resume my laptop and it establishes network 
connectivity, I will then *know* within a few seconds what TCP sessions 
are still valid (the ones that aren't will be killed either because 
they're bound to an IP that is not available, or a TCP packet is sent out 
to which there will be a TCP RST reply from the other side if the TCP 
session is closed at that end).

All of this also has implications on IPv6 and autoconfiguration, I don't 
know if currently we are closing TCP sessions bound to IPv6 addresses that 
are going away due to the RA the addresses were autoconfigured based on, 
now doesn't have a valid lifetime anymore and the kernel is going to 
remove them. It also applies to both DHCPv6 and DHCPv4 when a lease is 
expiring and the IPv4/IPv6 address is going to be removed.

Right now I think the situation with a lot of "hanging" TCP sessions after 
connectivity is restored is suboptimal and negatively impacts user 
experience. Probably there should be knobs to turn for different user 
needs (server or desktop/laptop) because desired behaviour is different in 
different use cases.

-- 
Mikael Abrahamsson    email: [email-masked]