Re: [tcpm] Is this a problem?

MURALI BASHYAM <> Tue, 06 November 2007 23:19 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IpXhS-0004uR-DB; Tue, 06 Nov 2007 18:19:14 -0500
Received: from tcpm by with local (Exim 4.43) id 1IpXhQ-0004tp-Te for; Tue, 06 Nov 2007 18:19:12 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1IpXhQ-0004th-IQ for; Tue, 06 Nov 2007 18:19:12 -0500
Received: from ([]) by with smtp (Exim 4.43) id 1IpXhP-0008VN-TU for; Tue, 06 Nov 2007 18:19:12 -0500
Received: (qmail 85125 invoked by uid 60001); 6 Nov 2007 23:19:11 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=r45jFQrDqJhW7XLZMUdhBM+Aa9z6i2mu5I8cCJlbDUKXtg8L+VyPCbUqhvlxHAkKz8AKCPyHozJkKo0Mql1ucw64zmDF0pSZSJFUAC9j/7OYkETMJ7a0zYRXCsQ0kiuRoN/h0eiK2zL0COhZOIjDrEhscnL5OZKtub1ELrmzWXg=;
X-YMail-OSG: K6bE3SEVM1kIAHs51n.olDjbRxhUoxLcQ5mv98307egRbPcaWJ_YqMLtG8Wwmp0LgA--
Received: from [] by via HTTP; Tue, 06 Nov 2007 15:19:11 PST
X-Mailer: YahooMailRC/814.05 YahooMailWebService/0.7.152
Date: Tue, 06 Nov 2007 15:19:11 -0800
Subject: Re: [tcpm] Is this a problem?
To: Joe Touch <touch@ISI.EDU>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID: <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
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: <>, <>

Writes may not block here, since there is space in the socket send buffer to accomodate the response tail.
We can't assume blocking writes to solve this issue.

If writes do not block, and the (tail of)  response fits in the send buffer queue, now the responsibility for
managing that data  is completely TCP's. TCP now needs an indication from the application to decide whether
to try to send that data indefinitely when the receiver continually advertises zero window or it has to implement a time bound as
requested by the app.  It's that simple, isn't it?


----- Original Message ----
From: Joe Touch <touch@ISI.EDU>
Cc: Ethan Blanton <>;; Lloyd Wood <>
Sent: Tuesday, November 6, 2007 2:27:18 PM
Subject: Re: [tcpm] Is this a problem?

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

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
> 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
> *cannot* (portably or cleanly) handle, at least under the Berkeley
> sockets API.  He is correct that once an application writes the end
> 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

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

tcpm mailing list