Re: [tcpm] Is this a problem?

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

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IpWtv-00015n-ET; Tue, 06 Nov 2007 17:28:03 -0500
Received: from tcpm by with local (Exim 4.43) id 1IpWtu-00014w-5L for; Tue, 06 Nov 2007 17:28:02 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1IpWtt-00014o-Ck for; Tue, 06 Nov 2007 17:28:01 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1IpWtq-0002XV-GA for; Tue, 06 Nov 2007 17:28:01 -0500
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id lA6MRYrL024256; Tue, 6 Nov 2007 14:27:35 -0800 (PST)
Message-ID: <>
Date: Tue, 06 Nov 2007 14:27:18 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
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: 32b73d73e8047ed17386f9799119ce43
Cc: Ethan Blanton <>,, 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="===============1681994954=="

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.


> 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 <>
> To: Joe Touch <touch@ISI.EDU>
> Cc: MURALI BASHYAM <>;; Lloyd Wood <>
> Sent: Tuesday, November 6, 2007 11:08:45 AM
> Subject: Re: [tcpm] Is this a problem?
> 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
>>> 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