Re: [tcpm] Is this a problem?

Ethan Blanton <> Tue, 06 November 2007 19:08 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IpTnH-0007Yl-M9; Tue, 06 Nov 2007 14:08:59 -0500
Received: from tcpm by with local (Exim 4.43) id 1IpTnH-0007Xk-1S for; Tue, 06 Nov 2007 14:08:59 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1IpTnG-0007XN-Ni for; Tue, 06 Nov 2007 14:08:58 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1IpTnD-0004mA-CJ for; Tue, 06 Nov 2007 14:08:58 -0500
Received: from [] ( by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from <>) id 1IpTn6-0003g0-7k; Tue, 06 Nov 2007 19:08:53 +0000
Received: from colt.internal (colt []) by (Postfix) with ESMTP id 040E52BE21; Tue, 6 Nov 2007 14:08:45 -0500 (EST)
Received: by colt.internal (Postfix, from userid 3000) id 43A7A283F2; Tue, 6 Nov 2007 14:08:45 -0500 (EST)
Date: Tue, 06 Nov 2007 14:08:45 -0500
From: Ethan Blanton <>
To: Joe Touch <touch@ISI.EDU>
Subject: Re: [tcpm] Is this a problem?
Message-ID: <>
Mail-Followup-To: Joe Touch <touch@ISI.EDU>, MURALI BASHYAM <>,, Lloyd Wood <>
References: <> <>
MIME-Version: 1.0
In-Reply-To: <>
X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: -102.8 (---------------------------------------------------)
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc:, Lloyd Wood <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============1431810457=="

Joe Touch spake unto us the following wisdom:
> > We want to limit the timer to the sender's persist state only, any
> > other timeout overloads the semantics of the application, and may also
> > cause unnecessary timeouts for the application. In fact there are
> > instances where the application may not even have the connection state
> > around to implement the timout correctly, like the tail of a long HTTP
> > response. After sending the tail of the response, the application can
> > close the connection and release its connection memory, during this
> > window only TCP has the connection state. We've done a lot of testing
> > and design for handling all these cases, and to implement this
> > correctly, we need TCP's involvement.
> It still sounds like you have a poorly written application to me; anyone
> else?

This comment of Murali's, specifically, is a case that the application
*cannot* (portably or cleanly) handle, at least under the Berkeley
sockets API.  He is correct that once an application writes the end of
its data and calls close() or shutdown(), the TCP socket may persist
indefinitely in the kernel, and the application would never know (if
there are no application-level acknowledgments, as there are not in
simple HTTP responses).

It does not seem unreasonable to add a zero-window timeout tunable to
any given TCP implementation; I don't necessarily think it is a TCP
standardization issue, however, as there is no wire impact.


The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
tcpm mailing list