Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document

David Borman <david.borman@windriver.com> Fri, 03 October 2008 21:06 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1DD228C0D8; Fri, 3 Oct 2008 14:06:00 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5556D28C0D8 for <tcpm@core3.amsl.com>; Fri, 3 Oct 2008 14:05:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.658
X-Spam-Level:
X-Spam-Status: No, score=-3.658 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bw5Ax0me-n0z for <tcpm@core3.amsl.com>; Fri, 3 Oct 2008 14:05:58 -0700 (PDT)
Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 80F593A6807 for <tcpm@ietf.org>; Fri, 3 Oct 2008 14:05:58 -0700 (PDT)
Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m93L6N2B016386; Fri, 3 Oct 2008 14:06:24 -0700 (PDT)
Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Oct 2008 14:04:51 -0700
Received: from dab-restive.wrs.com ([192.168.117.73]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Oct 2008 14:04:50 -0700
Message-Id: <BAEE6189-ADF3-4871-9687-156A6F33E41A@windriver.com>
From: David Borman <david.borman@windriver.com>
To: Murali Bashyam <mbcoder@gmail.com>
In-Reply-To: <9c8209a10810031237y470b9cd3ha8ad6cbc3e17e422@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Fri, 3 Oct 2008 16:04:48 -0500
References: <53797EED-2C93-4E20-AF60-E3C0EF8F85AC@windriver.com> <1e41a3230809292310o591b7f98l5048083b9e0966f2@mail.gmail.com> <EC7B72027914A242B991C029F5F213CF2AB0CCA6AA@exchsvr01.ocarina.local> <20081003183726.GD27519@zod.isi.edu> <9c8209a10810031237y470b9cd3ha8ad6cbc3e17e422@mail.gmail.com>
X-Mailer: Apple Mail (2.929.2)
X-OriginalArrivalTime: 03 Oct 2008 21:04:50.0812 (UTC) FILETIME=[ACECABC0:01C9259B]
Cc: "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, "tcpm@ietf.org" <tcpm@ietf.org>, Ted Faber <faber@isi.edu>, Murali Bashyam <MBashyam@ocarinanetworks.com>
Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

On Oct 3, 2008, at 2:37 PM, Murali Bashyam wrote:
>
> My intent was that even where TCP implementations have a scheme for   
> dropping connections in the event
> of resource exhaustion (such as the Linux one does), they have  
> excluded connections in this state.
> The point i am trying to convey is that the 1122 portion has  
> (mis)guided them in that direction.

If this is true, it should be clarified.  1122 does not in any way say  
that ABORT does not apply to connections in persist state (probing a  
zero window).

...
>> In light of that I think that the sentence about "TCP itself SHOULD
>> not[sic] take any action..." is more confusing than the 1122 section.
>> It seems to imply that TCP might react differently to an abort than
>> the single paragraph in 793, and I don't think that's the case.
>
> What's meant here is that it's okay for the connection to get  
> aborted in this state, whatever the mechanism for doing
> so maybe: TCP can abort the connection and inform the application,  
> similar to the retransmit/persist timeout mechanisms
> already in place, or the application can choose to abort the  
> connection based policy, or the OS can do so based
> on resource management criteria. We can re-word that sentence and  
> paragraph to reflect this.

Just to be clear: TCP DOES NOT ABORT THE CONNECTION!  The OS or the  
application can choose to ABORT the connection, but TCP does not make  
this decision.  TCP does have retransmit timers, and it is allowed to  
terminate unresponsive connections, but it does not abort connections  
just because they are in persist state for long periods of time.   
Until you are running out of resources there is no good reason to  
terminate connections in persist state, and when you are running out  
of resources, it is the OS that is deciding whether or not to ABORT  
any TCP connections.


>> Now, a strictly defined abort command seems to somewhat contradict my
>> earlier comments about allowing implementers some freedom.  This is a
>> spot where the standards body has required a specific tool to be
>> available to applications (and OSes and resource managers): there  
>> must
>> be a way to annihilate a TCP connection from outside without regard  
>> to
>> its state or anything else.  The standard is silent about how the
>> command is used; that's the flexibility here.
>
> The abort semantics as specified by 793 are clear, they are not  
> specific to a particular state, it's the opinion
> of the authors that 1122 excludes it from being applied in this state.

Yes, that is an opinion, but it is wrong.  In no way does 1122 say  
that connections in persist state cannot be ABORTed.  What 1122 does  
say is that a connection being in persist state for a long time is not  
sufficient reason *by itself* to terminate a TCP connection, i.e.,  
don't time it out like you would a connection to a non-responsive host.

			-David Borman


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