Subject: out-of-window SYNs ... what to do?

From: Jason Thorpe <[email-masked]>
Date: Tue, 26 Jan 1999 03:06:04 -0800

Hi folks...

While debugging a completely unrelated issue in the NetBSD kernel today,
I noticed some behavior which I felt warranted some discussion here (and
please forgive me if this horse has been beaten into mush already...)

The problem was observed between a diskless Network Computer (`client')
and home directory server for its workgroup (`server').

The two systems are using NFSv3 (over TCP) to communicate.

So, consider the following scenario:

	(1) client.1023 mounts server.2049.  This causes a TCP connection
	    to be established.

	(2) Power cord on client is pulled, and reinserted.  Client reboots.

Now, at this point, you have the server in ESTABLISHED state for this
connection.  The client thinks here is no connection.

	(3) client.1023 mounts server.2049.  This causes a TCP connection
	    to be established.

...except, the connection never completes.  Indeed, server never sends SYN,ACK
because out-of-window SYNs are simply dropped on the floor.

At this point, client is hosed.  The only way we can be unwedged is for the
server to send what it thinks is an in-window packet.  This can be either
a keepalive (very infrequent) or, if we're lucky, a retransmission of data
left un-ACK'd when the client went down (much more frequent).  This packet
will cause the client to generate an RST, which will cause the socket on
the server to close, which will cause the client's attempts to connect to
complete (since it will be a "fresh" connection at this point).

This behavior is probably technically correct (tho, at nearly 3am, I'm too
tired to go look it up right now).  However, the effect it produces is
annoying at best.

While brainstorming, some colleagues and I came up with the idea that
resending the last ACK for the current window would be a reasonable course
of action for the server to take in this situation (i.e. when it discovers
an out-of-window SYN for an established connection).  This would simply
expedite the discovery of the no-longer-established connection (by forcing
the client to send the RST sooner).

Anyhow, I'd appreciate some input on this...

Thanks!

        -- Jason R. Thorpe <[email-masked]>