Re: [tcpm] Is this a problem?

MURALI BASHYAM <> Tue, 06 November 2007 21:36 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IpW5w-0005Br-Nv; Tue, 06 Nov 2007 16:36:24 -0500
Received: from tcpm by with local (Exim 4.43) id 1IpW5v-0005BW-8P for; Tue, 06 Nov 2007 16:36:23 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1IpW5u-0005Af-Uj for; Tue, 06 Nov 2007 16:36:22 -0500
Received: from ([]) by with smtp (Exim 4.43) id 1IpW5r-0000Qn-El for; Tue, 06 Nov 2007 16:36:22 -0500
Received: (qmail 38852 invoked by uid 60001); 6 Nov 2007 21:36:18 -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=5j7AHkvCMgRJDkKxLRvZptGjHNgYwZ0mpaPnbhWYQrsrDgeuho4SDbHcDm70SADhgmt0FQghNdaPLzKTmGa2+izKhXTt6kjkeTzrMzRXBQTL01i6AUoAVFDJxMFPJCMh7z68HtIzBOU2pnCvG7YVZZwZbJfDQgkmbiwm8miyXmk=;
X-YMail-OSG: eDgQT7sVM1nhmJKYIvdFaa9mNFg0NDfjapCkrKnnjcLnWnDG4RBc9SMX0GaTtULkOWuysq5_JDr8uVaqK1SSkZELHbKbK9ITdR16WZmUo1ld0XM6Zqk-
Received: from [] by via HTTP; Tue, 06 Nov 2007 13:36:18 PST
X-Mailer: YahooMailRC/814.05 YahooMailWebService/0.7.152
Date: Tue, 06 Nov 2007 13:36:18 -0800
Subject: Re: [tcpm] Is this a problem?
To: Ethan Blanton <>, 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: c0bedb65cce30976f0bf60a0a39edea4
Cc:, 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: <>, <>

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


----- 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
> > cause unnecessary timeouts for the application. In fact there are
> > instances where the application may not even have the connection
> > around to implement the timout correctly, like the tail of a long
> > response. After sending the tail of the response, the application
> > close the connection and release its connection memory, during this
> > window only TCP has the connection state. We've done a lot of
> > 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;
> 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.


The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
        -- Cesare Beccaria, "On Crimes and Punishments", 1764

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

tcpm mailing list