Re: [tcpm] Is this a problem?

Joe Touch <touch@ISI.EDU> Tue, 06 November 2007 22:28 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 1IpWtv-00015n-ET; Tue, 06 Nov 2007 17:28:03 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpWtu-00014w-5L for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 17:28:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpWtt-00014o-Ck for tcpm@ietf.org; Tue, 06 Nov 2007 17:28:01 -0500
Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpWtq-0002XV-GA for tcpm@ietf.org; Tue, 06 Nov 2007 17:28:01 -0500
Received: from [75.212.24.145] (145.sub-75-212-24.myvzw.com [75.212.24.145]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lA6MRYrL024256; Tue, 6 Nov 2007 14:27:35 -0800 (PST)
Message-ID: <4730EA46.1000605@isi.edu>
Date: Tue, 06 Nov 2007 14:27:18 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: MURALI BASHYAM <murali_bashyam@yahoo.com>
Subject: Re: [tcpm] Is this a problem?
References: <895257.37528.qm@web31711.mail.mud.yahoo.com>
In-Reply-To: <895257.37528.qm@web31711.mail.mud.yahoo.com>
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: 32b73d73e8047ed17386f9799119ce43
Cc: Ethan Blanton <eblanton@cs.ohiou.edu>, tcpm@ietf.org, Lloyd Wood <L.Wood@surrey.ac.uk>
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="===============1681994954=="
Errors-To: tcpm-bounces@ietf.org

Yes, HTTP has head of line blocking on persistent connections.

If HTTP doesn't want to hang that connection forever on a pending
transfer, use blocking writes and terminate the connection on a timeout.

If HTTP doesn't want HOL blocking, don't use persistent connections.

Joe

MURALI BASHYAM wrote:
> The problem is also harder to solve in the HTTP context, for persistent connections, where the server
> can write the tail of the HTTP response to the connection send buffer, and then it keeps the connection around
> (i.e no app close) waiting for a new HTTP request from any clients out there. It has
> no way of detecting whether forward progress has been made for that particular response, because it is now
> completely in TCP's send buffer to deliver it. These are scenarios where it seems acceptable for TCP to accomodate
> what the application wants (don't hang indefinitely to deliver that response).
> 
> Murali
> 
> ----- Original Message ----
> From: Ethan Blanton <eblanton@cs.ohiou.edu>
> To: Joe Touch <touch@ISI.EDU>
> Cc: MURALI BASHYAM <murali_bashyam@yahoo.com>om>; tcpm@ietf.org; Lloyd Wood <L.Wood@surrey.ac.uk>
> Sent: Tuesday, November 6, 2007 11:08:45 AM
> Subject: Re: [tcpm] Is this a problem?
> 
> 
> 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).
> 
> 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.
> 
> Ethan
> 

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