Re: [tcpm] Is this a problem?

Joe Touch <touch@ISI.EDU> Wed, 21 November 2007 01:57 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1Iueqb-0000Ip-1f; Tue, 20 Nov 2007 20:57:49 -0500
Received: from tcpm by with local (Exim 4.43) id 1IueqZ-0000IS-B4 for; Tue, 20 Nov 2007 20:57:47 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1IueqZ-0000IK-0I for; Tue, 20 Nov 2007 20:57:47 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1IueqY-0006E3-Hk for; Tue, 20 Nov 2007 20:57:46 -0500
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id lAL1vTqw003427; Tue, 20 Nov 2007 17:57:31 -0800 (PST)
Message-ID: <>
Date: Tue, 20 Nov 2007 17:57:20 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20071031)
MIME-Version: 1.0
To: Chandrashekhar Appanna <>
Subject: Re: [tcpm] Is this a problem?
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.5
X-ISI-4-43-8-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
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: <>, <>
Content-Type: multipart/mixed; boundary="===============0800686058=="

Chandrashekhar Appanna wrote:
> On Tue, Nov 20, 2007 at 04:01:21PM -0800, Joe Touch wrote:
>>> The community standardised TCP window size advertisements. That's a local resource control issue, surely?
>> That's something you have to tell the other end, i.e., it requires a
>> change to the protocol on the wire. This one can be implemented without
>> any change to the protocol at all - entirely at the app layer.
>   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!!)

First, the argument above is that this is like standardizing TCP window

Second, the original argument was that this wasn't solvable at the app

The rationale changes and the arguments persists. That's useful to note, IMO

>>>> That seems absurd to me.  So, to me, arguing about where to mitigate the
>>>> persist stuff is putting the cart before the horse.  First, we'd need to
>>>> establish some reason to standardize local resource control.
>>> because it's useful?
>> 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.

TCP doesn't need this; users do. TCP doesn't care about hanging around -
or transmitting data very slowly. Some people call both a feature.


tcpm mailing list