Re: [tcpm] Is this a problem?

Lloyd Wood <> Tue, 20 November 2007 22:01 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1Iub9i-0000mj-Io; Tue, 20 Nov 2007 17:01:18 -0500
Received: from tcpm by with local (Exim 4.43) id 1Iub9h-0000mb-ER for; Tue, 20 Nov 2007 17:01:17 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1Iub9g-0000mT-O0 for; Tue, 20 Nov 2007 17:01:16 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1Iub9c-0004R6-J8 for; Tue, 20 Nov 2007 17:01:16 -0500
X-IronPort-AV: E=Sophos;i="4.21,443,1188770400"; d="scan'208";a="158306998"
Received: from ([]) by with ESMTP; 20 Nov 2007 23:01:11 +0100
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id lAKM1B7X001735; Tue, 20 Nov 2007 23:01:11 +0100
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id lAKM1BUm004796; Tue, 20 Nov 2007 22:01:11 GMT
Received: from ( []) by (8.8.8-Cisco List Logging/8.8.8) with ESMTP id WAA05926; Tue, 20 Nov 2007 22:01:10 GMT
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Tue, 20 Nov 2007 22:01:07 +0000
From: Lloyd Wood <>
Subject: Re: [tcpm] Is this a problem?
In-Reply-To: <>
References: <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Authentication-Results: ams-dkim-1;; dkim=neutral
X-Spam-Score: -4.0 (----)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
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: <>, <>

At Tuesday 20/11/2007 07:12 -0500, Mark Allman wrote:

>> Why does congestion control require standardization, when every
>> client/server application out there is perfectly capable of doing it?
>> To achieve consistent behaviour across the widest range of
>> applications...
>I think this is a complete mis-characterization.  The answer is that
>congestion control is standardized because congestion control is about
>dealing with a *shared resource*.  We can do that control from a number
>of places in the stack and people have advocated for each of them at
>different points.  But, *where* that functionality exists is a second
>question after we establish that the functionality needs to exist and we
>need to standardize on it.  This persist business is not about
>controlling a shared resource, but about controlling a *local
>resource*.  Why should the community standardize local resource control?

The community standardised TCP window size advertisements. That's a local resource control issue, surely?

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




tcpm mailing list