Re: [tcpm] Is this a problem?

Mahesh Jethanandani <> Wed, 21 November 2007 01:48 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1Iuehc-00062W-7x; Tue, 20 Nov 2007 20:48:32 -0500
Received: from tcpm by with local (Exim 4.43) id 1Iueha-0005nj-BA for; Tue, 20 Nov 2007 20:48:30 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1Iueha-0005ld-0Y for; Tue, 20 Nov 2007 20:48:30 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1IuehV-0003ad-UD for; Tue, 20 Nov 2007 20:48:29 -0500
Received: from ([]) by with ESMTP; 20 Nov 2007 17:48:25 -0800
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id lAL1mPjx005521 for <>; Tue, 20 Nov 2007 17:48:25 -0800
Received: from [] ( []) by (8.12.10/8.12.6) with ESMTP id lAL1mPGc000826 for <>; Wed, 21 Nov 2007 01:48:25 GMT
Message-ID: <>
Date: Tue, 20 Nov 2007 17:48:25 -0800
From: Mahesh Jethanandani <>
Organization: Cisco Systems Inc.
User-Agent: Thunderbird (Windows/20071031)
MIME-Version: 1.0
Subject: Re: [tcpm] Is this a problem?
References: <> <> <> <> <> <>
In-Reply-To: <>
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6315; t=1195609705; x=1196473705; 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=Mit0CI6qqyC0XmCw0TDRasN5XvuxuwSi14hOy3qdJEk=; b=ongyQ9/t+RCzooY7TjgYRo8yzud0Ka1i1KwIx+0H2kFJxsFoL3ZWQ3kM7mxE8TSdjUL5TYhu qTPOzqxgWXxdPje05yqVjivHjuaSDEtwIWJlaH6E/484lUijZg/meWOs;
Authentication-Results: sj-dkim-3;; dkim=pass ( sig from verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
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="===============1164088386=="

Ethan Blanton wrote:
>> And I think the authors are positioning that there is a better place
>> in the architecture to solve this and that is in tcp. I think it is
>> boiling down to just a matter of opinions so far.. esp when you keep
>> repeating that it could be solved in the app layer (for as long as I
>> recall!!)
> Joe keeps making this point because it is _very important_.  Any
> feature which can be accomplished at Layer N can be accomplished at
> Layer N - 1, and vice-versa.  However, the Internet protocols have
> enjoyed tremendous success and longevity in part because they resist
> the urge to push application and other high-layer semantics into the
> lower layers.
But  in case of congestion control it was felt that it would be done 
better in TCP. Why? After all nothing stopped applications from 
implementing congestion control.
>>> Useful is a fine metric for a new protocol, not for mucking with such a
>>> ubiquitous and established one unnecessarily, IMO.
>> I do not understand that line of reasoning at all.. I think the point
>> was that it could be useful to tcp.. not to some new protocol. I think
>> the discussion has to be around that point only.. last I checked this
>> was the tcp m mailing list.
> "Unnecessarily" is an important word in that statement, which you did
> not address.  The question has never been "can this be done in TCP",
> it is rather, "should this be done in TCP?"
> For my own part, I have not yet seen a reason why application layer
> timeouts are not a reasonable solution to this problem, or even the
> _correct_ solution to this problem, because only the application knows
> how much progress is "sufficient" progress, and as such I cannot see
> driving this feature into the TCP _standards_.  I also, however, see
> no reason why some particular TCP stack could not provide a socket
> tunable for persist timeout, if sufficient userspace demand were
> present.
We give reasons as to why a timeout in application will not work. For 
one, a fixed timeout is easy to defeat. If you are not proposing a fixed 
timeout, what kind of timeout are you proposing? Is it going to be based 
on that applications view of how many buffers it is holding on to? What 
if that application is not the problem, but some other application is? 
What if the other application does not even bother about connections in 
persist condition.

The problem is also that the resources in question are TCP resources and 
applications have a snapshot of the problem from their connection point 
of view. They do not see the problem that TCP is seeing.

tcpm mailing list