Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document
Murali Bashyam <MBashyam@OcarinaNetworks.com> Fri, 21 November 2008 07:33 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 B1C6C3A67D8; Thu, 20 Nov 2008 23:33:44 -0800 (PST)
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 CF1913A67D8 for <tcpm@core3.amsl.com>; Thu, 20 Nov 2008 23:33:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.536
X-Spam-Level:
X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.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 JdqKS7etu+Dd for <tcpm@core3.amsl.com>; Thu, 20 Nov 2008 23:33:42 -0800 (PST)
Received: from mail.ocarinanetworks.com (h-69-3-29-18.snvacaid.covad.net [69.3.29.18]) by core3.amsl.com (Postfix) with ESMTP id E4F573A67B4 for <tcpm@ietf.org>; Thu, 20 Nov 2008 23:33:41 -0800 (PST)
Received: from exchsvr01.ocarina.local ([10.250.1.7]) by exchsvr01.ocarina.local ([10.250.1.7]) with mapi; Thu, 20 Nov 2008 23:33:40 -0800
From: Murali Bashyam <MBashyam@OcarinaNetworks.com>
To: Murali Bashyam <MBashyam@OcarinaNetworks.com>, David Borman <david.borman@windriver.com>, Murali Bashyam <mbcoder@gmail.com>
Date: Thu, 20 Nov 2008 23:33:35 -0800
Thread-Topic: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document
Thread-Index: AcklnA2e2MXArg1GSAaMUO85RtQh+AAHXndQCXxc9OA=
Message-ID: <EC7B72027914A242B991C029F5F213CF2AB0F355CF@exchsvr01.ocarina.local>
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> <BAEE6189-ADF3-4871-9687-156A6F33E41A@windriver.com> <EC7B72027914A242B991C029F5F213CF2AB0CCA823@exchsvr01.ocarina.local>
In-Reply-To: <EC7B72027914A242B991C029F5F213CF2AB0CCA823@exchsvr01.ocarina.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Ted Faber <faber@isi.edu>, "tcpm@ietf.org" <tcpm@ietf.org>, "Anantha Ramaiah (ananth)" <ananth@cisco.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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org
Wes/David What are the next steps for this document to be considered a WG item? Can we get some closure on this draft? Thx, Murali > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Murali Bashyam > Sent: Saturday, October 04, 2008 9:49 PM > To: David Borman; Murali Bashyam > Cc: Anantha Ramaiah (ananth); tcpm@ietf.org; Ted Faber > Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document > > > > > -----Original Message----- > > From: David Borman [mailto:david.borman@windriver.com] > > Sent: Friday, October 03, 2008 2:05 PM > > To: Murali Bashyam > > Cc: Ted Faber; tcpm@ietf.org; Anantha Ramaiah (ananth); Murali > Bashyam > > Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document > > > > > > 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. > > I agree that the retransmit/persist timeout analogy doesn't apply to > this situation. > It is ONLY the OS or resource manager or the application that can > terminate the connection > In this state. > > > > > > > >> 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. > > Just so that we are all clear, i want to summarize the goals of the > draft here once again: > > 1. Clarify the 1122 ambiguity/stance on the sender behavior in persist > state. > 2. Document (for informational purpose) the consequence of this > behavior leading to > the DoS possibility. > 3. Specify that the OS/application can terminate the connection in this > state using the 793 ABORT interface. > > We are NOT documenting the various memory management > considerations/issues surrounding the DoS scenario, that's left to the > implementers discretion. > > We will change the section that's ambiguous regarding the sentence that > goes "TCP itself should not take any action...". > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm
- [tcpm] draft-ananth-tcpm-persist-00.txt as a WG d… David Borman
- Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a … Joe Touch
- Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a … John Heffner
- Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a … Ted Faber
- Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a … David Borman
- Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a … Joe Touch
- Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a … Ted Faber
- Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a … Eddy, Wesley M. (GRC-RCN0)[VZ]
- Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a … Murali Bashyam
- Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a … Joe Touch
- Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a … Murali Bashyam
- Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a … Joe Touch
- Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a … Ted Faber
- Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a … Murali Bashyam
- Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a … David Borman
- Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a … Ted Faber
- Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a … David Borman
- Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a … Murali Bashyam
- Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a … Murali Bashyam
- Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a … Eddy, Wesley M. (GRC-RCN0)[VZ]