From fanf@dotat.at  Thu Feb  8 17:28:43 2001
Return-Path: <fanf@dotat.at>
Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62])
	by hub.freebsd.org (Postfix) with ESMTP id BF01437B4EC
	for <FreeBSD-gnats-submit@freebsd.org>; Thu,  8 Feb 2001 17:28:42 -0800 (PST)
Received: from fanf by hand.dotat.at with local (Exim 3.20 #3)
	id 14R2MW-0002gK-00
	for FreeBSD-gnats-submit@freebsd.org; Fri, 09 Feb 2001 01:28:36 +0000
Message-Id: <E14R2MW-0002gK-00@hand.dotat.at>
Date: Fri, 09 Feb 2001 01:28:36 +0000
From: Tony Finch <dot@dotat.at>
Reply-To: Tony Finch <dot@dotat.at>
To: FreeBSD-gnats-submit@freebsd.org
Subject: properly delay acks in half-closed TCP connections
X-Send-Pr-Version: 3.2

>Number:         24962
>Category:       kern
>Synopsis:       properly delay acks in half-closed TCP connections
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    jesper
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Feb 08 17:30:03 PST 2001
>Closed-Date:    Tue May 29 12:50:29 PDT 2001
>Last-Modified:  Tue May 29 12:55:30 PDT 2001
>Originator:     Tony Finch
>Release:        FreeBSD 4.2-STABLE i386
>Organization:
Covalent Technologies, Inc.
>Environment:

FreeBSD hand.dotat.at 4.2-STABLE FreeBSD 4.2-STABLE #2: Thu Feb  8 08:45:48 GMT 2001     fanf@hand.dotat.at:/FreeBSD/obj/FreeBSD/releng4/sys/DELL-Latitude-CSx  i386

>Description:

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).''

>How-To-Repeat:

>Fix:

Index: tcp_input.c
===================================================================
RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v
retrieving revision 1.107.2.4
diff -u -r1.107.2.4 tcp_input.c
--- tcp_input.c	2000/08/16 06:14:23	1.107.2.4
+++ tcp_input.c	2001/02/08 22:58:38
@@ -176,7 +176,7 @@
 #define	TCP_REASS(tp, th, tlenp, m, so, flags) { \
 	if ((th)->th_seq == (tp)->rcv_nxt && \
 	    LIST_EMPTY(&(tp)->t_segq) && \
-	    (tp)->t_state == TCPS_ESTABLISHED) { \
+	    (tp)->t_state >= TCPS_ESTABLISHED) { \
 		if (tcp_delack_enabled) \
 			callout_reset(tp->tt_delack, tcp_delacktime, \
 			    tcp_timer_delack, tp); \

>Release-Note:
>Audit-Trail:

From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
To: Tony Finch <dot@dotat.at>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: kern/24962: properly delay acks in half-closed TCP connections
Date: Thu, 8 Feb 2001 21:12:18 -0500 (EST)

 <<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
 
 

From: Tony Finch <dot@dotat.at>
To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, Tony Finch <dot@dotat.at>
Subject: Re: kern/24962: properly delay acks in half-closed TCP connections
Date: Fri, 9 Feb 2001 02:23:54 +0000

 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.
 
Responsible-Changed-From-To: freebsd-bugs->jesper 
Responsible-Changed-By: jesper 
Responsible-Changed-When: Mon May 28 14:45:26 PDT 2001 
Responsible-Changed-Why:  
Will work on this 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=24962 
State-Changed-From-To: open->closed 
State-Changed-By: jesper 
State-Changed-When: Tue May 29 12:50:29 PDT 2001 
State-Changed-Why:  
Fix committed in -current, will MFC in about 2 weeks 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=24962 
>Unformatted:
