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

From: Mark Allman <[email-masked]>
Date: Thu, 01 Apr 2010 15:53:20 -0400

> 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?

allman

---

From: John Heffner <[email-masked]>
Date: Thu, 1 Apr 2010 16:40:31 -0400

> 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 think a good approach for an operating system implementor is to (1)
provide ABORT via a socket fd so individual applications can manage
their own connections, and (2) provide a system-wide nanny so admins
can provide some degree of safety even if applications aren't written
so carefully (obviously, most aren't).

(And, not to sound like a broken record, the receiver's current window
size should probably have nothing to do with whether the connection is
aborted.)

  -John

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Thu, 1 Apr 2010 13:54:57 -0700

Hi Mark, 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mark Allman
> Sent: Thursday, April 01, 2010 12:53 PM
> To: Murali Bashyam
> Cc: [email-masked]
> Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02
> 
> I mean, sure, an app may want to not let a connection hang 
> around forever.  But, can't it just ABORT whenever it wants?

Yes, the application can ABORT the connection whenever it wants. 

The socket option is suggested for multiple reasons (use cases) :-

- orphaned connections, where the application has already closed the
connection and the connection is in persist state.
- Typically when the data cannot be sent (due to retransmisions) there
is a retransmit timeout happening and a error ETIMEDOUT returned to the
application, for persist case there is no way for the application to
know about the connection not making any progress. When this socket
option is set, TCP would behave the same way as would for ETIMEDOUT
case.

The reason why the socket option is been suggested because we want to
preserve the default behaviour of persist forever but an override
suggested by the application if needed by means of a socket option. (or
sysctl or something equivalent). This ensures that we are not violating
RFC 1122.

Also this is an informational draft and typically one would want to
explain the situation better and some implementation advice, that is the
reason we have put the socket option in the appendix. Hope this
explanation conveys the functionality of the socket option, do you think
some clarfication are needed in the document?. (actually we have
received other comments too and will put all of them together when we
submit the next revision).

-Anantha

---

From: Mark Allman <[email-masked]>
Date: Thu, 01 Apr 2010 22:45:46 -0400

> The socket option is suggested for multiple reasons (use cases) :-

Well, that all strikes me as thin.  I mean, I don't actually care what
socket option anyone wants to add, but I agree with John that it doesn't
seem like IETF work to me.  I certainly wouldn't suggest doing it in a
draft that is meant as a simple clarification of previous RFCs.

I am fine with the simple clarification in this draft.  I would leave
off the API gunk.  Just my hit.

allman

---

From: Murali Bashyam <[email-masked]>
Date: Thu, 1 Apr 2010 21:07:28 -0700

The attempt here via the socket option etc is to describe a guideline to normalize the persist condition connection failure to the excessive retransmissions condition. Note that for the latter connection failure, RFC 1122 says TCP SHOULD inform the application unless the app has disabled asynchronous reporting of soft errors. Are you suggesting that the guideline is unnecessary or out of scope for this document?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, April 01, 2010 7:46 PM
To: Anantha Ramaiah (ananth)
Cc: Murali Bashyam; [email-masked]
Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 

> The socket option is suggested for multiple reasons (use cases) :-

Well, that all strikes me as thin.  I mean, I don't actually care what socket option anyone wants to add, but I agree with John that it doesn't seem like IETF work to me.  I certainly wouldn't suggest doing it in a draft that is meant as a simple clarification of previous RFCs.

I am fine with the simple clarification in this draft.  I would leave off the API gunk.  Just my hit.

allman

---

From: Joe Touch <[email-masked]>
Date: Sat, 03 Apr 2010 10:59:42 -0700

> 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.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Sat, 03 Apr 2010 20:27:31 -0300

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

I agree with Joe here.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Mark Allman <[email-masked]>
Date: Wed, 07 Apr 2010 22:57:56 -0400

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

Yep.  We should clarify and be done with it.  The hooks to let the app
do something smart if it cares enough to do so are already either there
or specified.

allman

---

From: Fernando Gont <[email-masked]>
Date: Thu, 08 Apr 2010 00:50:30 -0300

> do something smart if it cares enough to do so are already either there

FWIW, this SO_LINGER option predates Linux. It was already covered in
Stevens' UNP series, which didn't cover Linux (IIRC).

IMO, we don't need RFC 1122 (or whatever) to allow us to abort (i.e.,
ABORT()) connections (despite the reason). The ABORT procedure was
already defined in RFC 793, and there were no contraints at all wrt
*when* a TCP user is allowed to call it.

Thanks,