Re: [tcpm] Is this a problem?

Mark Allman <mallman@icir.org> Wed, 21 November 2007 00:25 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IudP3-0000Z5-NT; Tue, 20 Nov 2007 19:25:17 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IudP2-0000WA-KM for tcpm-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 19:25:16 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IudP2-0000W2-9W for tcpm@ietf.org; Tue, 20 Nov 2007 19:25:16 -0500
Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IudP1-0003az-RB for tcpm@ietf.org; Tue, 20 Nov 2007 19:25:16 -0500
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id lAL0PE63029796; Tue, 20 Nov 2007 16:25:15 -0800
Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id A7F291229CB6; Tue, 20 Nov 2007 19:25:04 -0500 (EST)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 5A95C2F8228; Tue, 20 Nov 2007 18:10:00 -0500 (EST)
To: Lloyd Wood <L.Wood@surrey.ac.uk>
From: Mark Allman <mallman@icir.org>
Subject: Re: [tcpm] Is this a problem?
In-Reply-To: <200711202201.WAA05926@cisco.com>
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Walk on the Wild Side
MIME-Version: 1.0
Date: Tue, 20 Nov 2007 18:10:00 -0500
Message-Id: <20071120231000.5A95C2F8228@lawyers.icir.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: mallman@icir.org
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2071769356=="
Errors-To: tcpm-bounces@ietf.org

Lloyd-

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

The community has not standardized TCP window size advertisements.  And,
you know it.  The community has standardized an encoding to allow the
end points of a TCP connection to exchange information.  What is your
point?

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

We disagree on that point.  I certainly can understand that connections
consume local resources and this is something that a system (OS, TCP,
app, whatever) will want to control.  But, I don't agree that we can
determine one global definition of "useful" local resource control that
will hold for everyone.  Should we tell Cisco how to allocate socket
buffers while we're at it?

allman



_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm