Re: [tcpm] poll for adoption of draft-ananth-persist-02

Joe Touch <touch@ISI.EDU> Tue, 23 March 2010 06:59 UTC

Return-Path: <touch@ISI.EDU>
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 218133A6930 for <tcpm@core3.amsl.com>; Mon, 22 Mar 2010 23:59:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.431
X-Spam-Level: **
X-Spam-Status: No, score=2.431 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=2.431]
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 UWR1G-lCKh2P for <tcpm@core3.amsl.com>; Mon, 22 Mar 2010 23:59:32 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 5ADB03A6890 for <tcpm@ietf.org>; Mon, 22 Mar 2010 23:59:32 -0700 (PDT)
Received: from [130.129.28.166] (dhcp-wireless-open-abg-28-166.meeting.ietf.org [130.129.28.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o2N6vnpB020289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Mar 2010 23:57:52 -0700 (PDT)
Message-ID: <4BA8666D.7050106@isi.edu>
Date: Mon, 22 Mar 2010 23:57:49 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Murali Bashyam <MBashyam@OcarinaNetworks.com>
References: <C304DB494AC0C04C87C6A6E2FF5603DB47DF997794@NDJSSCC01.ndc.nasa.gov> <1e41a3231003221441s57d77a53m255fbe8c00cb370@mail.gmail.com> <4BA7FFA2.4020800@cisco.com> <1e41a3231003221915n45b07a07v3a0ace6a879bb4e9@mail.gmail.com> <EC7B72027914A242B991C029F5F213CF3EBF2678DE@exchsvr01.ocarina.local>
In-Reply-To: <EC7B72027914A242B991C029F5F213CF3EBF2678DE@exchsvr01.ocarina.local>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4C99127AFDB08E01B1F9C94F"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02
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: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Tue, 23 Mar 2010 06:59:33 -0000

First, John is talking about Section 7 of your doc.

Second, there are a few parts of the doc that do need to be discussed,
notably anything that goes beyond "and it's always been the case that a
TCP connection can be terminated by the OS". In particular, Section 7
defines an API that is beyond the scope of this recommendation, IMO.

But that's separate from taking this doc on. Let's finish that decision
first, right?

Joe

Murali Bashyam wrote:
> There is no Section 7 in RFC 1122. 
> 
> Section 4.2.2.17 states that "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." This is the guideline that implementations have followed.
> 
> 
> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of John Heffner
> Sent: Monday, March 22, 2010 7:15 PM
> To: Mahesh Jethanandani
> Cc: tcpm@ietf.org
> Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02
> 
> On Mon, Mar 22, 2010 at 7:39 PM, Mahesh Jethanandani <mahesh@cisco.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> John,
>>
>> On 3/22/2010 2:41 PM, John Heffner wrote:
>>> I read the new version of this draft.  For the record, my opinion
>>> hasn't changed since the -00 version, which is that publication of
>>> this draft as an RFC would be harmful.  I don't object to the simple
>>> clarifying statement that a connection may be aborted while in the
>>> persist state.  (I'm not sure this requires a new RFC.)  However, this
>>> draft goes beyond that, implying that connections should be aborted
>>> *because* they are in persist state.
>> Where in the draft do we imply that "connections should be aborted
>> *because* they are in persist state"? We are not implying that
>> connections SHOULD be aborted because they are in persist state. Instead
>> we are suggesting that connections should be *allowed* to be aborted in
>> persist state. Currently RFC 1122 language is ambiguous in this regard
>> when connections go into indefinite wait in ZWP condition.
> 
> I'm pretty sure Section 7 describes automatically aborting connections
> because they are in the persist state for some period of time.
> 
>   -John
> _______________________________________________
> 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