Re: [tcpm] Is this a problem?

Jakob Heitz <jheitz@redback.com> Wed, 21 November 2007 07:13 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 1Iujlv-0008FF-QL; Wed, 21 Nov 2007 02:13:19 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iujlt-0008F9-O0 for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 02:13:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iujlt-0008F1-B3 for tcpm@ietf.org; Wed, 21 Nov 2007 02:13:17 -0500
Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iujlq-0002oB-Kj for tcpm@ietf.org; Wed, 21 Nov 2007 02:13:17 -0500
Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 23013CA6C4F; Tue, 20 Nov 2007 23:13:14 -0800 (PST)
Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11044-01; Tue, 20 Nov 2007 23:13:14 -0800 (PST)
Received: from [127.0.0.1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id D2ACECA6C4D; Tue, 20 Nov 2007 23:13:13 -0800 (PST)
Message-ID: <4743DA89.6080300@redback.com>
Date: Tue, 20 Nov 2007 23:13:13 -0800
From: Jakob Heitz <jheitz@redback.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Lloyd Wood <L.Wood@surrey.ac.uk>
Subject: Re: [tcpm] Is this a problem?
References: <200711202201.WAA05926@cisco.com> <20071120231000.5A95C2F8228@lawyers.icir.org> <200711210546.FAA00566@cisco.com>
In-Reply-To: <200711210546.FAA00566@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at redback.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: tcpm@ietf.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>
Errors-To: tcpm-bounces@ietf.org

RFC2581 specifies behaviour of a host to protect
the network. This is in the interest of all network
users, thus subject to standardization.

The problem of the subject line is a problem of one
host, the solution to which is confined to that
same host. The solution does not affect the network
and requires no change in behaviour of any other
host on the network. Thus it is not subject to
standardization by a network standards body.

The fact that a host chooses to implement TCP in
something it calls a "kernel" is a private matter
of that host and nothing that the rest of the network
is the least bit interested in.

Any host is free to fix this problem with something
it might call a "socket option" or anything else
without violating any IETF standards, nor requiring
any blessing of the IETF.

The IETF does not say that you must keep all TCP
connections alive if you run out of resources,
does it?

Lloyd Wood wrote:
> At Tuesday 20/11/2007 18:10 -0500, Mark Allman wrote:
>> 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. 
> 
> okay, e.g. RFC3390 and RFC2581 are marked standards-_track_. But those implicitly suggest how you are expected to have local resources available (congestion/loss window buffer) to meet communication conventions for shared use for a shared goal - communication. (Hmm, indicating when one side should stop communicating doesn't really fit in with the shared goal of communication.)
> 
> At what point does a resource stop being shared and start being local (or vice versa)? It seems a bit fuzzy to me.
> 
> L. 


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