Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]

Lloyd Wood <L.Wood@surrey.ac.uk> Tue, 27 November 2007 11:30 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 1Iwye2-00041I-HY; Tue, 27 Nov 2007 06:30:26 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iwye0-00041B-Qy for tcpm-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 06:30:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwydv-0003s4-95 for tcpm@ietf.org; Tue, 27 Nov 2007 06:30:19 -0500
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwydr-0002ma-Q1 for tcpm@ietf.org; Tue, 27 Nov 2007 06:30:19 -0500
X-IronPort-AV: E=Sophos;i="4.23,219,1194217200"; d="scan'208";a="158876090"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 27 Nov 2007 12:30:13 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lARBUCs0003127; Tue, 27 Nov 2007 12:30:12 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lARBUBZZ015330; Tue, 27 Nov 2007 11:30:11 GMT
Received: from lwood-wxp01.cisco.com (rtp-vpn3-67.cisco.com [10.82.216.67]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA11778; Tue, 27 Nov 2007 11:30:09 GMT
Message-Id: <200711271130.LAA11778@cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 27 Nov 2007 11:30:06 +0000
To: Joe Touch <touch@ISI.EDU>
From: Lloyd Wood <L.Wood@surrey.ac.uk>
Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]
In-Reply-To: <474B92FA.7020902@isi.edu>
References: <20071126163305.326192FC402@lawyers.icir.org> <474AFB2A.9080504@isi.edu> <200711262103.VAA27187@cisco.com> <474B92FA.7020902@isi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Authentication-Results: ams-dkim-2; header.From=L.Wood@surrey.ac.uk; dkim=neutral
X-Spam-Score: -4.0 (----)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: tcpm@ietf.org, mallman@icir.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

At Monday 26/11/2007 19:46 -0800, Joe Touch wrote:
>Lloyd Wood wrote:
>> At Monday 26/11/2007 08:58 -0800, Joe Touch wrote:
>> 
>>> I see an OS that has to decide how to allocate resources:
>>>
>>>        a- leave them with existing apps and prohibit new ones
>>>
>>>        b- terminate existing apps to make room for new ones
>>>
>>> I expect that a reasonable, modern OS would do (a).
>> 
>> That presumes that all TCP connections are long-lived. It permits a
>> few long-lived connections to tie up resources that could service
>> short-lived connections.
>> 
>> (http, beep, xml-rpc and other short-lived transactions over TCP
>> weren't invented when RFC1122 was written.) 
>
>It presumes only that a connection shouldn't be terminated to make room
>for new ones. It says nothing about the duration of the connection.

well, obviously. that's because all connections were presumed to be long-lived.


>1122 says that connections that are active - i.e., actively exchanging
>packets - MUST NOT be terminated. 

If only it said connections actively exchanging data...


>Connections are terminated only when
>applications indicate, OR when the endpoints cannot communicate.
>
>If you start "robbing Peter to pay Paul" - i.e., killing some
>connections to make room for others - you end up with a very unreliable
>kind of TCP. One where connections just disappear.

I'd argue we have that unreliable TCP already - e.g. varying # of SYNs repeated to ensure a connection is opened on different OSs, with different application behaviour as a result. Your connection just disappeared because the SYN and the sole repeat Windows sends were lost? Hit reload in your web browser! (How applications handle end-to-end reliability across TCP is a separate problem, but the end-to-end argument suggests that TCP can be unreliable - it's not the highest level.)


>Modern OS's don't kill apps to make room for new ones (presuming they're
>static in resource use). This is the connection equivalant.

What's the connection equivalent of swapping an unused app out to virtual memory and forgetting about it?

L.


>I agree that having the OS - who is SOLELY in view of shared resources -
>informing the application when resources are critical, and applications
>being designed to decide which connections to keep and which to drop
>based on *knowlege about the connections they alone possess*.
>
>However, once a connection is opened, I don't agree that it's the OS's
>perogative to kill it for any reason, any more than it would kill a
>process that isn't running away. Holding resources already granted is
>how current app/OS interfaces work; revocation isn't normal.
>
>Yes, this means that *applications* can be DOS attacked, and they need
>to be written to react accordingly.
>
>Joe


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