Re: [tcpm] Is this a problem?

MURALI BASHYAM <> Tue, 06 November 2007 18:51 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IpTVs-0007Hn-C2; Tue, 06 Nov 2007 13:51:00 -0500
Received: from tcpm by with local (Exim 4.43) id 1IpTVr-0007Hh-1X for; Tue, 06 Nov 2007 13:50:59 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1IpTVq-0007Gr-Mh for; Tue, 06 Nov 2007 13:50:58 -0500
Received: from ([]) by with smtp (Exim 4.43) id 1IpTVq-0007m6-9D for; Tue, 06 Nov 2007 13:50:58 -0500
Received: (qmail 66101 invoked by uid 60001); 6 Nov 2007 18:50:56 -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=XjXyrGcJ3i64p1jDacy4D6Hcj8S52PrmoqvoHGCCCZ90egDY4Dj1A7OWpbp4oczniJ2MtvaqTkwWcc9b+P9CTp+7qpVAntB9FoEVzEe+4DFp7T4NxOR9ZsSZEVWGDCXPhy/Jdow7Ii5guQodv79wNxwiADY+kSPTJGMuxiExuqs=;
X-YMail-OSG: IRB.CfkVM1nKO7vlR7ms5YL2tyVTDjLgpTrVsjl8ikm2heV76vAeGGLOR8jzPiXuZHkfCetPGsAdJ1y_ItIKSUiXzAaCJhcg.IltW7sFuIG.acDq6Ik-
Received: from [] by via HTTP; Tue, 06 Nov 2007 10:50:50 PST
X-Mailer: YahooMailRC/814.05 YahooMailWebService/0.7.152
Date: Tue, 06 Nov 2007 10:50:50 -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: cab78e1e39c4b328567edb48482b6a69
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: <>, <>

This behaviour can and does get exhibited by standard web servers also, it's not only our application. The solution must 
work in scenarios where the application can cleanup its connection state, expecting TCP to deliver the data reliably to the peer after that.
It's not a broken application, this is a perfectly legal scenario. As far as the app is concerned, it's done with that connection, it can devote
that connection memory and resources  to another user or client, thus increasing goodput.

----- Original Message ----
From: Joe Touch <touch@ISI.EDU>
Cc: Lloyd Wood <>;
Sent: Tuesday, November 6, 2007 10:40:10 AM
Subject: Re: [tcpm] Is this a problem?

> 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
> 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;


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

tcpm mailing list