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

John Heffner <jheffner@psc.edu> Mon, 26 November 2007 19:42 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 1IwjqC-0003jx-VT; Mon, 26 Nov 2007 14:42:00 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IwjqB-0003js-DZ for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 14:41:59 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwjqB-0003jk-2u for tcpm@ietf.org; Mon, 26 Nov 2007 14:41:59 -0500
Received: from mailer2.psc.edu ([128.182.66.106]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwjqA-0003Fv-Lr for tcpm@ietf.org; Mon, 26 Nov 2007 14:41:59 -0500
Received: from [128.182.160.132] (ice.psc.edu [128.182.160.132]) (authenticated bits=0) by mailer2.psc.edu (8.14.1/8.13.3) with ESMTP id lAQJfr4b017999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2007 14:41:56 -0500 (EST)
Message-ID: <474B2181.7050103@psc.edu>
Date: Mon, 26 Nov 2007 14:41:53 -0500
From: John Heffner <jheffner@psc.edu>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]
References: <20071126142635.8F2E62FBFFD@lawyers.icir.org> <474AEBB4.9010803@isi.edu>
In-Reply-To: <474AEBB4.9010803@isi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
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

Joe Touch wrote:
> 
> Mark Allman wrote:
>> [hat off]
>>
>> I am not sure where in this thread to weigh in, so I am just replying to
>> the last thing in my inbox.
>>
>> I think a couple of things:
> ...
>>   + I disagree with the reading of RFCs 793 & 1122 that a connection
>>     that is doing zero window probing must remain up forever as long as
>>     the probes are being ACKed.  I think in 'times of trouble' a TCP is
>>     well within its rights to terminate a connection and I do not think
>>     that should in any way be viewed as non-compliant.  TCP connections
>>     are local resources and therefore should remain under local
>>     control.  If something locally determines that resources are low and
>>     connection should be terminated for whatever reason then I don't see
>>     how that is any of anyone else's business.
> 
> The point of 1122 is that TCP isn't the one to decide this, AND that
> connections with zero windows with ACKs aren't to be singled out.
> Applications can kill connections, and certainly the OS can just shut
> down. However, an OS that decides to kill connections because it runs
> out of resources is noncompliant.
> 
> That OS is required to reserve per-connection resources when connections
> are created. It can halt new connections.
> 
> It *CANNOT* kill existing connections to make up for poor resource
> management and call itself compliant with the current language in 1122.


I really have to disagree here; I do not believe an OS terminating a 
connection violates the spirit of 1122.  Things like processes, address 
spaces, etc., are well outside the TCP standard's realm.  In my view, an 
operating system (the kernel, a helper daemon, or other) can be 
considered a "User" of TCP (in RFC793 terminology), and be fully 
compliant when making API calls (including ABORT) to connections that 
might be "owned" by some other process.

One question: is the deleteTCB(12) state of RFC4022 in conflict with 
RFC1122/RFC793?

   -John



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