Re: [tcpm] Is this a problem?

Joe Touch <touch@ISI.EDU> Tue, 06 November 2007 19:13 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IpTrm-0005tp-DX; Tue, 06 Nov 2007 14:13:38 -0500
Received: from tcpm by with local (Exim 4.43) id 1IpTrk-0005py-Ol for; Tue, 06 Nov 2007 14:13:36 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1IpTrk-0005pb-Dd for; Tue, 06 Nov 2007 14:13:36 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1IpTrj-0000Ec-Tq for; Tue, 06 Nov 2007 14:13:36 -0500
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id lA6JCPxc029806; Tue, 6 Nov 2007 11:12:26 -0800 (PST)
Message-ID: <>
Date: Tue, 06 Nov 2007 11:12:09 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>, MURALI BASHYAM <>,, Lloyd Wood <>
Subject: Re: [tcpm] Is this a problem?
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.5
X-ISI-4-43-8-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
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="===============0076362326=="

Ethan Blanton wrote:
> 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).

Why would a blocking CLOSE not solve that?

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

Protocols are more than just what is on the wire. They include state at
the endpoints, and APIs.


tcpm mailing list