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

Joe Touch <touch@ISI.EDU> Fri, 03 October 2008 00:54 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 F3CD428C0D9; Thu, 2 Oct 2008 17:54:59 -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 077F83A6A77 for <tcpm@core3.amsl.com>; Thu, 2 Oct 2008 17:54:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.587
X-Spam-Level:
X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=1.012, BAYES_00=-2.599, GB_I_LETTER=-2]
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 tinkeW6eb+rN for <tcpm@core3.amsl.com>; Thu, 2 Oct 2008 17:54:58 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 28D0C3A6B0E for <tcpm@ietf.org>; Thu, 2 Oct 2008 17:54:58 -0700 (PDT)
Received: from [192.168.1.45] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m930snwF028768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Oct 2008 17:54:51 -0700 (PDT)
Message-ID: <48E56D59.7010004@isi.edu>
Date: Thu, 02 Oct 2008 17:54:49 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Murali Bashyam <MBashyam@OcarinaNetworks.com>
References: <53797EED-2C93-4E20-AF60-E3C0EF8F85AC@windriver.com> <1e41a3230809292310o591b7f98l5048083b9e0966f2@mail.gmail.com> <EC7B72027914A242B991C029F5F213CF2AB0CCA6AA@exchsvr01.ocarina.local>
In-Reply-To: <EC7B72027914A242B991C029F5F213CF2AB0CCA6AA@exchsvr01.ocarina.local>
X-Enigmail-Version: 0.95.7
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, "tcpm@ietf.org" <tcpm@ietf.org>, David Borman <david.borman@windriver.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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Murali Bashyam wrote:
...
>> I have reservations about moving forward with this draft as a wg
>> document.  While the information is technically correct, it is overly
>> specific to the point of possibly being misleading rather than
>> clarifying.  An operating system may terminate a tcp connection at any
>> time, not just when the connection is in the persist state.  Further,
>> I would actually argue that terminating a connection *because* it's in
>> the persist state is a bad idea and should be discouraged.  (The
>> reason for termination should be for its use of resources, not TCP's
>> state.)
> 
> No implementation today (the well-known ones BSD, Windows and Linux)
> terminates the TCP connection in that persist state as long as ACKs are
> being reliably received from the peer.

No OS I'm aware of cleans much of anything up when it runs out of space.
They tend to just run out of space and silently hang or thrash incessently.

The point is that an OS that wants to do this can. That's an OS
implementation recommendation that I support - the question is whether
such OS implementation issues are useful as RFCs.

> Those three implementations are
> not doing what you are saying they should be doing, and if it's crystal
> clear from the standard that they should be doing so, why aren't they?

The standard already says, IMO, that they MAY do this. Not that they
MUST. The standard says nothing about what to do when you run out of
resources to run the connections you're currently supporting - it says
nothing about what to do when new connections arrive in that state
either. Memory management is the OS's job, not the protocol's.

> They are all following the letter of the standard (1122) which dictates
> that they MUST do so. Linux even has a comment in the code that says RFC
> 1122 prevents it from doing so.

That's a great reason to:
	a) write code to enable this behavior in the OS's you
	want to fix
	b) correct the Linux comment

This is all an OS implementation issue, not a protocol standards issue.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjlbVkACgkQE5f5cImnZrs/fQCfYqFOdyjmg9aVMxyuMjY2eDZd
svkAnjvVH/Rq5E93BOsp5A/ZzKv4LBjL
=p3nQ
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm