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

Murali Bashyam <> Tue, 23 March 2010 07:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9B273A6813 for <>; Tue, 23 Mar 2010 00:34:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.745
X-Spam-Level: *
X-Spam-Status: No, score=1.745 tagged_above=-999 required=5 tests=[AWL=1.021, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M35HX87w516B for <>; Tue, 23 Mar 2010 00:34:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0C4203A67FB for <>; Tue, 23 Mar 2010 00:34:16 -0700 (PDT)
Received: from exchsvr01.ocarina.local ([]) by exchsvr01.ocarina.local ([]) with mapi; Tue, 23 Mar 2010 00:36:21 -0700
From: Murali Bashyam <>
To: Joe Touch <touch@ISI.EDU>
Date: Tue, 23 Mar 2010 00:36:17 -0700
Thread-Topic: [tcpm] poll for adoption of draft-ananth-persist-02
Thread-Index: AcrKVrAaOmSTAaWkTnKE2BSbeqBFWQAAK8/A
Message-ID: <EC7B72027914A242B991C029F5F213CF3EBF2678E2@exchsvr01.ocarina.local>
References: <> <> <> <> <EC7B72027914A242B991C029F5F213CF3EBF2678DE@exchsvr01.ocarina.local> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Mar 2010 07:34:16 -0000

Ok, I misunderstood the reference, my mistake.

This email discussion is for the adoption, and we are making a case for it purely based on the recommendation of 1122, and the consequent behavior of the widely deployed implementations out there under these conditions (wait indefinitely).
Given this data, it beats me as to where the disagreement about adoption can be.

-----Original Message-----
From: Joe Touch [mailto:touch@ISI.EDU] 
Sent: Monday, March 22, 2010 11:58 PM
To: Murali Bashyam
Cc: John Heffner; Mahesh Jethanandani;
Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02

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?


Murali Bashyam wrote:
> There is no Section 7 in RFC 1122. 
> Section 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: [] On Behalf 
> Of John Heffner
> Sent: Monday, March 22, 2010 7:15 PM
> To: Mahesh Jethanandani
> Cc:
> Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02
> On Mon, Mar 22, 2010 at 7:39 PM, Mahesh Jethanandani <> wrote:
>> 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 mailing list