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

Joe Touch <touch@ISI.EDU> Sat, 03 April 2010 18:01 UTC

Return-Path: <touch@ISI.EDU>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AE8D3A698E for <>; Sat, 3 Apr 2010 11:01:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s-ylc3P8GVpU for <>; Sat, 3 Apr 2010 11:01:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 01D7B3A69C5 for <>; Sat, 3 Apr 2010 11:01:11 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id o33HxhUK025881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Apr 2010 10:59:45 -0700 (PDT)
Message-ID: <>
Date: Sat, 03 Apr 2010 10:59:42 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20100228)
MIME-Version: 1.0
To: John Heffner <>
References: <EC7B72027914A242B991C029F5F213CF3EBF3BAB5B@exchsvr01.ocarina.local> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enig3EC84FF8311D04FDF785DA93"
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: "" <>, Murali Bashyam <>,
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: Sat, 03 Apr 2010 18:01:30 -0000

John Heffner wrote:
> On Thu, Apr 1, 2010 at 3:53 PM, Mark Allman <> wrote:
>>> There are other aspects too, it's also important for the application
>>> to control the duration that the connection spends in persist state,
>>> this is planned to be accomplished via a socket option.
>> Why?
>> I mean, sure, an app may want to not let a connection hang around
>> forever.  But, can't it just ABORT whenever it wants?
> I suspect one reason this has become an issue is that the sockets
> interface does not provide ABORT semantics, so it's not possible on
> most operating systems to write an application that is able to avoid
> tying up kernel memory.  I'm not sure this is an IETF issue, though.

I don't think so either. RFC 793 specifies an API (including ABORT), but
not how it is instantiated.

It looks like this is already possible, though:

Linux has abort via: CLOSE after SO_LINGER(l_onoff=nonzero, l_linger=0)

FreeBSD has a sysctl_drop accessible by TCPCTL_DROP

There appears to be a userland command for this called tcpdrop, too.