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

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Mon, 8 Mar 2010 13:49:31 -0600

The authors have updated draft-ananth-persist, and asked
us to poll the TCPM WG to have this particular document
adopted with an Informational target.

http://www.ietf.org/id/draft-ananth-tcpm-persist-02.txt

This has been discussed to some extent on the mailing
list and at the Dublin meeting.  The authors have
responded to comments received thus far and updated the
document as it grew from the outcome of prior feedback
on the draft-mahesh-persist-timeout document.

Please respond if you either:

(1) Support making this document a WG document with the
    target for Informational.

(2) Oppose making this document a WG document.

Of course, other comments are also welcome :).

It's relatively short, so if people could respond in the
next 2 weeks, this would allow us to determine consensus
during the week of the IETF meeting.

--
Wes Eddy
MTI Systems

---

From: Mark Allman <[email-masked]>
Date: Mon, 22 Mar 2010 15:11:18 -0400

> Of course, other comments are also welcome :).

I think (1) is fine.  I don't really think this document is needed, but
I also don't think it hurts anything as a clarification.  It could also
be a bit more clear and succinct.  A few comments below, but in general
"eh, whatever".

allman

Section 1:

  - I find this ...

      It is important to remember that ACK (acknowledgement) segments
      that contain no data are not reliably transmitted by TCP.
      Therefore zero window probing SHOULD be supported to prevent a
      connection from hanging forever if ACK segments that re-opens the
      window is lost.

    confusing.  I understand the first sentence, but I cannot parse the
    second.  I can guess what it is trying to say, but it needs fixed.

Section 3:

  - The sender does not necessarily dump "all" data into the send
    queue.  It depends on how big the send buffer is and how much data
    needs to be sent.

Section 5:

  - This:

      It also suggests that TCP MUST not abort any connection until
      either explicitly requested by the application to do so.
      
    makes no sense.  

    Is that "MUST not" or "MUST NOT".

    Usually there are two options after an "either", but I see only
    one.  I would normally think this is a spurious "either", but here
    am somehow thinking there is an option that was forgotten.

Meta:

  - Isn't the overall point of this document to clarify things to say
    that (1) a TCP cannot tear down a connection itself, (2) the
    application can abort a connection and (3) the OS can abort a
    connection?  If I am remembering this right then this could and
    should be called out **much** better in the document.

---

From: Murali Bashyam <[email-masked]>
Date: Mon, 22 Mar 2010 12:23:03 -0700

As an FYI, I wanted to point out the purpose of this document at a high level. It is to clarify that it is OK for connections to be aborted in the ZWP state (which entity is not the subject here), currently the language of RFC 1122 has caused confusion about this and has been interpreted by implementers to mean an "indefinite wait" and is amply substantiated by the fact that none of the widely deployed implementations (BSD, linux and windows) have got this aspect right, i.e they exhibit marked differences in their handling of this condition. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Allman
Sent: Monday, March 22, 2010 12:11 PM
To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
Cc: [email-masked]
Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02

> Of course, other comments are also welcome :).

I think (1) is fine.  I don't really think this document is needed, but I also don't think it hurts anything as a clarification.  It could also be a bit more clear and succinct.  A few comments below, but in general "eh, whatever".

allman

Section 1:

  - I find this ...

Section 3:

Section 5:

  - This:

    makes no sense.  

Meta:

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 Mar 2010 13:01:13 -0700

Mark Allman wrote:
> I also don't think it hurts anything as a clarification.

That's my view as well.

Joe

---

From: John Heffner <[email-masked]>
Date: Mon, 22 Mar 2010 17:41:42 -0400

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.

In practical terms, what is the difference between a connection in
persist state, and one where a receiver acknowledges one byte of data
every 10 seconds, never advertising a zero window?

  -John

On Mon, Mar 8, 2010 at 3:49 PM, Eddy, Wesley M. (GRC-MS00)[ASRC
AEROSPACE CORP] <[email-masked]> wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 22 Mar 2010 16:39:14 -0700

John,

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

> every 10 seconds, never advertising a zero window?

The objective of the current draft is to clarify the state of
connections in persist condition. A one byte acknowledgment takes the
connection out of persist condition which is out of the scope of this draft.

>> during the week of the IETF meeting.

- -- 
*Mahesh Jethanandani*

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 Mar 2010 18:07:00 -0700

Mahesh Jethanandani wrote:
> persist state. 

FWIW, that's my view.

> Currently RFC 1122 language is ambiguous in this regard

I don't think that's true, however. RFC 1122 never mandates that an
endsystem cannot terminate a connection this way.

I'm ambivalent to this as well, I don't see the need for this doc, but
also don't see the harm.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 22 Mar 2010 18:30:51 -0700

> 
> I don't think that's true, however. RFC 1122 never mandates 
> that an endsystem cannot terminate a connection this way.
> 
> I'm ambivalent to this as well, I don't see the need for this 
> doc, but also don't see the harm.

The problem is that all popular running implementations (BSD, Linux
etc.,) have difficulties interpreting the RFC 1122 language in the way
it is supposed to be interpreted which can lead to DOS scenario if
properly not mitigated. That is the whole reason of coming up with this
short draft. All these were discussed in the WG and the rough consensus
of the WG was that it is ok to have this clarified in the form of a
document. If there is anything that needs to be re-worded etc., to make
this clear, we can address that.

Thanks,
-Anantha

---

From: John Heffner <[email-masked]>
Date: Mon, 22 Mar 2010 22:15:14 -0400

On Mon, Mar 22, 2010 at 7:39 PM, Mahesh Jethanandani <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> John,
>

I'm pretty sure Section 7 describes automatically aborting connections
because they are in the persist state for some period of time.

  -John

---

From: Murali Bashyam <[email-masked]>
Date: Mon, 22 Mar 2010 23:38:47 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of John Heffner
Sent: Monday, March 22, 2010 7:15 PM
To: Mahesh Jethanandani
Cc: [email-masked]
Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02

  -John

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 Mar 2010 23:57:49 -0700

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

---

From: Murali Bashyam <[email-masked]>
Date: Tue, 23 Mar 2010 00:36:17 -0700

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:[email-masked]] 
Sent: Monday, March 22, 2010 11:58 PM
To: Murali Bashyam
Cc: John Heffner; Mahesh Jethanandani; [email-masked]
Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02

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:
>>> persist state.  (I'm not sure this requires a new RFC.)  However, 
>>> this draft goes beyond that, implying that connections should be 
>>> aborted
>> 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.
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 23 Mar 2010 10:11:16 -0700

> because they are in the persist state for some period of time.

Since your concern is about the wording of section 7 you can help us
reword it to remove any doubts that you might have.

Do you want to do that?

- -- 
*Mahesh Jethanandani*

---

From: John Heffner <[email-masked]>
Date: Tue, 23 Mar 2010 14:35:11 -0400

Here's all I think needs to be said (at all, not just section 7), but
I'm a minimalist. :)

----
Section 4.2.2.17 of RFC 1122 states:

            A TCP MAY keep its offered receive window closed
            indefinitely.  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.

To clarify, the above statement is not meant to restrict the ABORT
command [RFC793] in any way.  TCP should react to an ABORT in the same
way regardless of the current receive window.
----

  -John

On Tue, Mar 23, 2010 at 1:11 PM, Mahesh Jethanandani <[email-masked]> wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJLqPY0AAoJEP9ZPWIqKBmiVssH/2Lp7nO/3c36Ehjbs6hWL6HW
> gq2fGRz/SR6dm0ZR1551LfpCNSuC3Jn53DYjGILSFr2m2kzrh9KSFgjKEzBHssE0
> 8WYih30ufdTv6M9XYGhrlLq5uX5bgDAlEJP4NfmjS4B9BgW5DP95rG3PN+r/jCCb
> mLFIuOjhGyZfCYEniZHnT+TpyPS71msaLzKrXCFnWHY1Y1ybaHz8lHp9oBykTIpv
> AwE90PHSRCWP/RHYmr9d7hAagJ6Xmuruh4KSomn3BsbZHzxpOAQ8SkdHXAuPcv9u
> 4iBIQtXlz5X7EseJcORxHPV6e2OISizjkcIBxZ9qOo3hr/w0HteW50hZMbCyGjg=
> =PAr7
> -----END PGP SIGNATURE-----
>

---

From: Murali Bashyam <[email-masked]>
Date: Tue, 23 Mar 2010 15:23:19 -0700

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. Both *OS and application* need to control the duration that a connection spends in the persist state.

There are scenarios when the application releases its connection state after writing all the data into the socket (so called orphan connections), and after this if the TCP connection enters into a ZWP condition, the application does not have the connection state to issue the ABORT, but if it has setup the socket option before, then TCP can still enforce the specified duration.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Heffner
Sent: Tuesday, March 23, 2010 11:35 AM
To: Mahesh Jethanandani
Cc: [email-masked]
Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02

----

  -John