Bug 24962

Summary:

properly delay acks in half-closed TCP connections

Product:

Base System

Reporter:

Tony Finch <dot>

Component:

kern

Assignee:

Jesper Skriver <jesper>

Status:

Closed FIXED

Severity:

Affects Only Me

Priority:

Normal

Version:

4.2-STABLE

Hardware:

Any

OS:

Any

Attachments:

Description	Flags
file.diff	none

Description Tony Finch 2001-02-09 01:30:03 UTC

On page 47 of TCP/IP Illustrated, Volume 3, Stevens says:

``One question is why does the client immediately ACK the first two of the
three server replies, since they arrive in a short amount of time (44ms)?
The answer is in the TCP_REASS macro (p. 908 in Volume 2), which is invoked
for each segment of data received by the client. Since the client's end
of the connection enters the FIN_WAIT_2 state then segment 4 is processed,
the test in TCP_REASS for whether the state is ESTABLISHED fails, causing
an immediate ACK instead of a delayed ACK. This "feature" is not unique
to T/TCP but can be seen with the Net/3 code whenever one end half-closes
a TCP connection and enters the FIN_WAIT_1 or FIN_WAIT_2 state. From that
point on, every segment of data from the peer is immediately ACKed. The
test for the ESTABLISHED state in the TCP_REASS macro prevents data from
being passed to the application before the three-way handshake completes.
There is no need to immediately ACK in-sequence data when the connection
state is greater than ESTABLISHED (i.e. this test should be changed).''

Comment 1 Garrett A. Wollman 2001-02-09 02:12:18 UTC

<<On Fri, 09 Feb 2001 01:28:36 +0000, Tony Finch <dot@dotat.at> said:

> +	    (tp)->t_state >= TCPS_ESTABLISHED) { \

Should use the appropriate macro rather than assuming a particular
ordering on the TCP states.  In this case, TCPS_HAVEESTABLISHED(state).

-GAWollman

Comment 2 Tony Finch 2001-02-09 02:23:54 UTC

Garrett Wollman <wollman@khavrinen.lcs.mit.edu> wrote:
><<On Fri, 09 Feb 2001 01:28:36 +0000, Tony Finch <dot@dotat.at> said:
>
>> +	    (tp)->t_state >= TCPS_ESTABLISHED) { \
>
>Should use the appropriate macro rather than assuming a particular
>ordering on the TCP states.  In this case, TCPS_HAVEESTABLISHED(state).

I noticed later that NetBSD and OpenBSD have both inlined that macro
at the single place it is invoked.

Tony.
-- 
f.a.n.finch    fanf@covalent.net    dot@dotat.at
MALIN HEBRIDES BAILEY: VARIABLE BECOMING SOUTHEASTERLY 3 OR 4, INCREASING 6 OR
7, OCCASIONALLY GALE 8 IN BAILEY LATER. RAIN LATER. GOOD BECOMING MODERATE.

Comment 3 Jesper Skriver freebsd_committer

2001-05-28 22:45:26 UTC

Responsible Changed
From-To: freebsd-bugs->jesper

Will work on this

Comment 4 Jesper Skriver freebsd_committer

2001-05-29 20:50:29 UTC

State Changed
From-To: open->closed

Fix committed in -current, will MFC in about 2 weeks