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

Murali Bashyam <MBashyam@OcarinaNetworks.com> Tue, 23 March 2010 06:36 UTC

Return-Path: <MBashyam@OcarinaNetworks.com>
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 143023A69B7 for <tcpm@core3.amsl.com>; Mon, 22 Mar 2010 23:36:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.765
X-Spam-Level: **
X-Spam-Status: No, score=2.765 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=2.431, IP_NOT_FRIENDLY=0.334]
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 eBNMOZWKKJtd for <tcpm@core3.amsl.com>; Mon, 22 Mar 2010 23:36:46 -0700 (PDT)
Received: from mail.ocarinanetworks.com (mail.ocarinanetworks.com [69.3.29.22]) by core3.amsl.com (Postfix) with ESMTP id 2DC0E3A69B4 for <tcpm@ietf.org>; Mon, 22 Mar 2010 23:36:46 -0700 (PDT)
Received: from exchsvr01.ocarina.local ([10.250.1.7]) by exchsvr01.ocarina.local ([10.250.1.7]) with mapi; Mon, 22 Mar 2010 23:38:51 -0700
From: Murali Bashyam <MBashyam@OcarinaNetworks.com>
To: John Heffner <johnwheffner@gmail.com>, Mahesh Jethanandani <mahesh@cisco.com>
Date: Mon, 22 Mar 2010 23:38:47 -0700
Thread-Topic: [tcpm] poll for adoption of draft-ananth-persist-02
Thread-Index: AcrKLvSsbJhV1HnYQweQxSqhZK7bjQAItxKg
Message-ID: <EC7B72027914A242B991C029F5F213CF3EBF2678DE@exchsvr01.ocarina.local>
References: <C304DB494AC0C04C87C6A6E2FF5603DB47DF997794@NDJSSCC01.ndc.nasa.gov> <1e41a3231003221441s57d77a53m255fbe8c00cb370@mail.gmail.com> <4BA7FFA2.4020800@cisco.com> <1e41a3231003221915n45b07a07v3a0ace6a879bb4e9@mail.gmail.com>
In-Reply-To: <1e41a3231003221915n45b07a07v3a0ace6a879bb4e9@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:36:47 -0000

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