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

Joe Touch <touch@ISI.EDU> Fri, 03 October 2008 07:20 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 AA2253A6975; Fri, 3 Oct 2008 00:20:49 -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 AE8993A686A for <tcpm@core3.amsl.com>; Fri, 3 Oct 2008 00:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.852
X-Spam-Level:
X-Spam-Status: No, score=-2.852 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599]
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 CTkHeUt3b88C for <tcpm@core3.amsl.com>; Fri, 3 Oct 2008 00:20:47 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 13ED03A6A59 for <tcpm@ietf.org>; Fri, 3 Oct 2008 00:20:38 -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 m937JaTA016803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Oct 2008 00:19:38 -0700 (PDT)
Message-ID: <48E5C788.60005@isi.edu>
Date: Fri, 03 Oct 2008 00:19:36 -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> <48E56D59.7010004@isi.edu> <EC7B72027914A242B991C029F5F213CF2AB0CCA6BB@exchsvr01.ocarina.local>
In-Reply-To: <EC7B72027914A242B991C029F5F213CF2AB0CCA6BB@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: David Borman <david.borman@windriver.com>, "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

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



Murali Bashyam wrote:
...
> 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.
> 
>> Which standard are u referring to? I'm quoting from RFC 1122, page 91
>> the section on probing zero windows :
> 
>> "As long as the receiving TCP continues to send acknowledgments in response to the
>> Probe segments, the sending TCP MUST allow the connection to stay open."
>>
>> Can you point me to the word "MAY" in that sentence that you are referring to?

It's implied by the conditional. I.e., if the receiving TCP stops
sending ACKs, the sending TCP can drop the connection.

As to the sending side, there's the ABORT call in 793 - which we
discussed on this list before. The point is that _TCP_ can't decide to
stop the connection because of the TCP state of the other end, the local
TCP state, or behavior on the wire. Nothing in 793 says that the OS
can't kill the connection - any connection - at any time.

>> The important thing here is to clarify that sentence and the sender's behaviour
>> and prevent what appears to be a conflict between memory management
and protocol violation.

Please describe anywhere in 1122 or 793 where memory management is
described.

As I've noted before, this isn't a protocol violation - it's a failure
of an OS to support arbitrary numbers of instances of a protocol.

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

iEYEARECAAYFAkjlx4cACgkQE5f5cImnZrvVIACgy317tNIROKQF8JMq1b3osIEc
4bkAoNG6gnVh3RQ3ZXGe0nStL3ot2QVY
=plLF
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm