Re: bad interaction between TCP delayed ack and RSTs

[Ignatios Souvatzis <is%netbsd.org@localhost>]

On Tue, Jun 16, 2009 at 03:08:27AM -0400, Joanne M Mikkelson wrote:

> This is what is happening:
> 
> - The client sends some data.
> - Delayed ack causes NetBSD to send no ack for this packet.
> - The client exits (or closes the socket).
> - Windows sends an RST/ACK to close the TCP connection (it does this a
>   lot, if not most of the time -- I do not know when it uses a FIN).

Ahem. IMHO, the problem isn't that a RST is lost. It is that it is
sent at all!

Closing down a TCP connection is supposed to happen with
->FIN, <- FIN+ACK, ->ACK if I recall correctly.

This takes care of lost packets, retransmissions, etc. That's why
there are the FIN_WAIT_$N states.

Sending a RST is declaring that the TCP connection means "what ever
you (the receiver) hallucinate about this TCP connection is not
valid at my end, period." for an apparently open (to the receiver)
connection ( or "I don't want to open that connection" for a TCP
SYN).

So it's faster, the RST sending site doesn't have to keep state
about the connection, and it just doesn't work correctly - because
if it arrives at the other end before the unacknowledged data have
been handled, they are lost.

I believe the RST checking foo in our code is for a partial defense
against 3rd-party rogue RSTs. It's not meant, and can't be, to ACK
data-on-the-fly when a RST is receive- because by definition, when 
a RST arrives, there is no consensus about any data possibly being 
on the fly at all.

So either the application programmers have forgotten to do some
proper TCP flushing/closing call (I don't know the Windows API),
or Windows does a local optimization at the expense of reliability,
or some "firewall" in between does something very fishy.

Maybe one of our TCP gurus can correct be, but I think what I wrote
is in any Introduction To Networking. See, e.g., Tanenbaum, Computer
Networks, 3rd Edition, p. 532.

        -is
-- 
seal your e-mail: http://www.gnupg.org/