Re: [tcpm] Is this a problem?

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

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpTrm-0005tp-DX; Tue, 06 Nov 2007 14:13:38 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpTrk-0005py-Ol for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 14:13:36 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpTrk-0005pb-Dd for tcpm@ietf.org; Tue, 06 Nov 2007 14:13:36 -0500
Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpTrj-0000Ec-Tq for tcpm@ietf.org; Tue, 06 Nov 2007 14:13:36 -0500
Received: from [75.212.119.228] (228.sub-75-212-119.myvzw.com [75.212.119.228]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lA6JCPxc029806; Tue, 6 Nov 2007 11:12:26 -0800 (PST)
Message-ID: <4730BC89.5000909@isi.edu>
Date: Tue, 06 Nov 2007 11:12:09 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>, MURALI BASHYAM <murali_bashyam@yahoo.com>, tcpm@ietf.org, Lloyd Wood <L.Wood@surrey.ac.uk>
Subject: Re: [tcpm] Is this a problem?
References: <121882.10140.qm@web31702.mail.mud.yahoo.com> <4730B50A.1030102@isi.edu> <20071106190845.GC5881@elb.elitists.net>
In-Reply-To: <20071106190845.GC5881@elb.elitists.net>
X-Enigmail-Version: 0.95.5
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc:
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0076362326=="
Errors-To: tcpm-bounces@ietf.org


Ethan Blanton wrote:
> Joe Touch spake unto us the following wisdom:
>> MURALI BASHYAM wrote:
>>> 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.

Joe

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm