Re: [tcpm] Is this a problem?

Mahesh Jethanandani <> Tue, 30 October 2007 01:21 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1Imfnb-0007X6-OV; Mon, 29 Oct 2007 21:21:43 -0400
Received: from tcpm by with local (Exim 4.43) id 1ImfnZ-0007Ww-JR for; Mon, 29 Oct 2007 21:21:41 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1ImfnZ-0007Wk-7f for; Mon, 29 Oct 2007 21:21:41 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1ImfnY-0005HL-Nr for; Mon, 29 Oct 2007 21:21:41 -0400
X-IronPort-AV: E=Sophos;i="4.21,345,1188802800"; d="scan'208,217";a="244167043"
Received: from ([]) by with ESMTP; 29 Oct 2007 17:19:45 -0700
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id l9U0JiWu014825; Mon, 29 Oct 2007 17:19:44 -0700
Received: from [] ( []) by (8.12.10/8.12.6) with ESMTP id l9U0JiTg024245; Tue, 30 Oct 2007 00:19:44 GMT
Message-ID: <>
Date: Mon, 29 Oct 2007 17:19:43 -0700
From: Mahesh Jethanandani <>
Organization: Cisco Systems Inc.
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Caitlin Bestler <>
Subject: Re: [tcpm] Is this a problem?
References: <> <78C9135A3D2ECE4B8162EBDCE82CAD7702765252@nekter>
In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7702765252@nekter>
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5988; t=1193703584; x=1194567584; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20Mahesh=20Jethanandani=20<> |Subject:=20Re=3A=20[tcpm]=20Is=20this=20a=20problem? |Sender:=20; bh=bEGetLokrzcZkNGpXiTfVoizN0CIXg77z68INaGpx9w=; b=SK7oqmvrrKuxDx2nIWbh/cdTTl7H422nVeFBYNnjm3xzMo6fknsKxh8XevIBATf7bVNZGaaR dSCysilgGJQCTdyg+Y3Mrhji1lmmBhFAJlqua8uQnKLkZH96LoLwdlI0;
Authentication-Results: sj-dkim-3;; dkim=pass ( sig from verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250
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="===============0897820725=="


Caitlin Bestler wrote:
> This is indeed a problem. I'm just not convinced it's a transport problem.
> Only the application layer has enough information to know when a client's
> behavior is abusive and/or suspicious.
Applications if anything have less knowledge than TCP on why a 
connection is not making progress. In this particular case, HTTP could 
not make a distinction between a connection not making progress because 
of congestion in the network or because the client is advertising zero 
window. And yet all Apache can do is to reset the connection after a 
fixed amount of time. Again, HTTP may know how many of its connections 
are in the stuck state, it will not know how many FTP connections are 
seeing the same issue or how seriously constrained the system is.

We have found that a fixed timeout also does not work. It is easy to 
guess and work around as we did with our client program.

The solution has to be adaptive to the condition which in this case 
involves TCP and applications have little knowledge of the state of all 
of TCP connections.
> The transport layer should remain
> militantly ignorant of these matters.
When it impacts TCP's ability to function, I can hardly see that being 
ignorant will help.
tcpm mailing list