Subject: [Gen-art] Gen-ART telechat review of draft-ietf-tcpm-persist-04.txt

From: Brian E Carpenter <[email-masked]>
Date: Sun, 05 Jun 2011 08:15:51 +1200

Please see attached review.

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sat, 4 Jun 2011 14:51:53 -0700

Hi Brian,
    Sorry about the delay, I had chatted with the co-authors and have been wanting to reply to this email, but just found time.

I am enclosing the original and the responses. Responses are prefixed with ANA> for easier readability.

=============================================== Last call comments ========================================
[Responses are prefixed with ANA>]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-tcpm-persist-04.txt
Reviewer: Brian Carpenter
Review Date: 2011-06-05
IETF LC End Date: 2011-06-03
IESG Telechat date: 2011-06-09

Summary: Almost ready, but...
--------

Comment: 
--------

(These are my Last Call comments, to which I've seen no response so far.)

ANA> apologies for the delay.

I have no problem with the message of this draft, but there are problems in
the way the message is delivered.

Major issues:
-------------

Why is this Informational? If it matters, it should be a Standards Track
document updating RFC 1122.

ANA> I agree, it should have been a standards track document since it clarifies the RFC 1122 wording. I believe the TCPM chairs and WG group had 
ANA> approved us to come up with a informational RFC that clarifies the intention of RFC 1122 regarding persist state. We have no problems making ANA> this a standards track, I'll leave it to the chairs to comment on this.

If it's not a Standards Track document, why is it using RFC 2119 language?

ANA> I think we need to remove the RFC 2119 language if the target is informational.

"  The problem is applicable to TCP and TCP derived flow-controlled
   transport protocols like SCTP."

This statement is not much use on its own. Does this draft apply to SCTP?
If it does, which text in the SCTP spec is affected?

ANA> SCTP persist state handling is the same as recommended for TCP. RFC 4960 isn't very clear about this aspect, but it supports the receiver 
ANA> keeping its window open indefinitely.. section 6.1 from RFC 4960 :

      If the sender continues to receive new packets from the receiver
      while doing zero window probing, the unacknowledged window probes
      should not increment the error counter for the association or any
      destination transport address.  This is because the receiver MAY
      keep its window closed for an indefinite time.  Refer to Section
      6.2 on the receiver behavior when it advertises a zero window.
      The sender SHOULD send the first zero window probe after 1 RTO
      when it detects that the receiver has closed its window and SHOULD
      increase the probe interval exponentially afterwards.  Also note
      that the cwnd SHOULD be adjusted according to Section 7.2.1.  Zero
      window probing does not affect the calculation of cwnd.
ANA> I remember checking with Randall Stewart on the applicability of this draft to SCTP before we made this claim.. but we are open to any 
ANA> suggestion here.

Important editorial issues:
---------------------------

The draft says:

(begin quote from draft-ietf-tcpm-persist-04)
1.  Introduction

   Section 4.2.2.17 of Requirements for Internet Hosts [RFC1122] says:

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

      DISCUSSION:

         It is extremely important to remember that ACK (acknowledgment)
         segments that contain no data are not reliably transmitted by
         TCP.
(end quote from draft-ietf-tcpm-persist-04)

The closing quotation mark is incorrectly placed - it belongs after 
'TCP.' not after 'open.'. The reader will be misled by this. You might
consider even clearer flags for the extract, as I have used above.

ANA> Sure we can fix this. Good catch.

(begin quote from draft-ietf-tcpm-persist-04)
5.  Clarification Regarding RFC 1122 Requirements

   As stated in Requirements for Internet Hosts [RFC1122], a TCP
   implementation MUST NOT close a connection merely because it seems to
   be stuck in the ZWP or persist condition.  Unstated in RFC 1122, but
   implicit for system robustness, a TCP implementation MUST allow
   connections in the ZWP or persist condition to be closed or aborted
   by their applications or other resource management routines in the
   operating system.
(end quote from draft-ietf-tcpm-persist-04)

Both these sentences seem to assert things about RFC 1122, and about the state
of mind of its editor, that I have no reason to believe. RFC 1122 doesn't
say anything about the MUST NOT being "merely because" anything - the statement
in section 4.2.2.17 is completely unambiguous. And I don't see any grounds for
asserting that the second sentence is any way implicit in RFC 1122. Quite the
opposite - you are documenting an oversight. I think you should say so. For
example:

5.  Update to RFC 1122 Requirements

   Requirements for Internet Hosts [RFC1122] states that a TCP
   implementation MUST NOT close a connection if it seems to
   be stuck in the ZWP or persist condition, as long as ackowledgements
   are being received. The present document updates this requirement by
   adding that a TCP implementation MUST allow connections in the ZWP
   or persist condition to be closed or aborted by their applications or
   other resource management routines in the operating system.

ANA> Excellent catch!.  I am comfortable using the above text which you suggested. 

Minor editorial
---------------

These are examples - I think the English needs a general tidy-up:

"  Per Requirements for Internet Hosts [RFC1122] as long as the ACK's
   are being received for window probes, a connection can continue to
   stay in the persist condition."

The use of "Per" like this is, well, sloppy. "According to..." would be better.
There is a missing comma after "[RFC1122]".
"ACK's" should be "ACKs".

ANA> Point taken, will correct it.

"  Systems that adhere too strictly to the above verbiage of
   Requirements for Internet Hosts [RFC1122]..."

It isn't "verbiage", which means "The use of many words without necessity, or with 
little sense; a superabundance of words; verbosity; wordiness" according to my 
favourite on-line dictionary. It is just "wording".

ANA> I think even other IESG reviewer also pointed this out (Stewart ?) Corrected already I guess, if not will correct it.

ANA> Thanks for your valuable comments, Brain. Will incorporate them.

ANA> As far as the comment on standards track versus informational, my preference was to go with standards since it can be construed as a update 
ANA> to RFC 1122. I'll leave it to the chairs to comment further on this.  I am also copying David Harrington in the loop since his question 
ANA> also centered around the RFC 2119 language...

============================================ End Last call comments ==============================

Thanks,
-Anantha
> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Saturday, June 04, 2011 1:16 PM
> To: [email-masked]; General Area Review
> Team
> Subject: Gen-ART telechat review of draft-ietf-tcpm-persist-04.txt
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 05 Jun 2011 16:09:46 +1200

Hi Wes,

> In TCPM, it was determined that RFC 1122 is not wrong or flawed, just
> potentially unclear. 

That's a judgment call that the WG's entitled to make, of course.

(Side comment: it would be useful for reviewers outside the WG
if writeups noted why a document was in a particular category
when there might be some question about it.)

> There are many non-standards-track RFCs that include 2119 language,

True, where the document is self-contained (e.g. an Experimental
specification). But it goes with my previous point - either it's
normative, in which case it should be standards track, or it isn't,
in which case using RFC 2119 seems inconsistent.

This is definitely IMHO but I see from Dave Harrington's DISCUSS that
he has the same questions.

Regards
   Brian Carpenter

On 2011-06-05 15:08, Wesley Eddy wrote:
> Just commenting on the non-editorial portion:
> 
> On 6/4/2011 5:51 PM, Anantha Ramaiah (ananth) wrote:
>>
>> ...
>>
>> ANA>  I agree, it should have been a standards track document since it
>> clarifies the RFC 1122 wording. I believe the TCPM chairs and WG group
>> had
>> ANA>  approved us to come up with a informational RFC that clarifies
>> the intention of RFC 1122 regarding persist state. We have no problems
>> making ANA>  this a standards track, I'll leave it to the chairs to
>> comment on this.
> 
> In TCPM, it was determined that RFC 1122 is not wrong or flawed, just
> potentially unclear.
> 
> The current draft is a clarification rather than actually augmenting,
> correcting, extending, or updating any of the specs and guidance in
> 1122.
> 
> As I recall, Informational was purposefully chosen by TCPM; this is
> more implementation guidance than anything warranting standards track.
> As for adding Updates 1122, this may be a good idea; I don't recall if
> it was specifically discussed by the WG.  I noticed at least one other
> RFC which includes clarifications is Informational and doesn't Update
> its parent documents (RFC 4718 is the example)
> 
> 
> There are many non-standards-track RFCs that include 2119 language, so
> it's unclear what the hangup is here.  That said, I think either way,
> the meaning of this document will be clear, so don't have strong
> personal feelings one way or the other.
> 
>

---

From: Wesley Eddy <[email-masked]>
Date: Sat, 04 Jun 2011 23:08:06 -0400

-- 
Wes Eddy
MTI Systems

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sun, 5 Jun 2011 00:21:20 -0700

So, I am a bit confused, just to summarize my understanding so far :-

- if the document status is standards track, then there is no issue.
- if the document status is informational, then remove the RFC 2119 usage. Then I am afraid the message of the draft becomes at the best dubious.
- retain it as informational, but use "updates 1122". Can this be done? I am not sure..

How do we move forward on this one?

-Anantha

> Sent: Saturday, June 04, 2011 9:10 PM
> To: Wesley Eddy
> Cc: Anantha Ramaiah (ananth); draft-ietf-tcpm-
> [email-masked]; General Area Review Team; David Harrington
> Subject: Re: Gen-ART telechat review of draft-ietf-tcpm-persist-04.txt
> 
> Hi Wes,
> 
> >> ANA>  I think we need to remove the RFC 2119 language if the target
> is
> >> informational.
> >
> so

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Jun 2011 08:16:03 +1200

Hi,

As my review said - please wait for instructions from the document
shepherd. The IESG discussion is what counts. My opinion is only
my opinion.

Regards
   Brian

---

From: "SCHARF, Michael" <[email-masked]>
Date: Sun, 5 Jun 2011 22:39:01 +0200

I am not sure whether there was or would be WG consensus for standards
track. We might have to ask the WG that question.

Compared to that, removing RFC 2119 language could probably be a much
simpler and faster solution. And I don't understand why that would
affect the content of the draft that much.

Michael

> From: Anantha Ramaiah (ananth) [mailto:[email-masked]] 
> Sent: Sunday, June 05, 2011 9:21 AM
> To: Brian E Carpenter; Wesley Eddy
> Cc: [email-masked]; General Area 
> Review Team; David Harrington
> Subject: RE: Gen-ART telechat review of draft-ietf-tcpm-persist-04.txt
> 
> - if the document status is informational, then remove the 
> RFC 2119 usage. Then I am afraid the message of the draft 
> becomes at the best dubious.
> > > In TCPM, it was determined that RFC 1122 is not wrong or flawed, 
> > > just potentially unclear.
> > 
> > (Side comment: it would be useful for reviewers outside the WG if 
> > writeups noted why a document was in a particular category 
> when there 
> > normative, in which case it should be standards track, or 
> it isn't, in 
> > which case using RFC 2119 seems inconsistent.
> > 
> > >> Why is this Informational? If it matters, it should be a 
> Standards
> > Track
> > >> ANA>  I agree, it should have been a standards track 
> document since
> > it
> > >> ANA>  approved us to come up with a informational RFC that 
> > >> ANA> clarifies
> > > In TCPM, it was determined that RFC 1122 is not wrong or flawed, 
> > > just potentially unclear.
> > >
> > > The current draft is a clarification rather than actually 
> > > augmenting, correcting, extending, or updating any of the 
> specs and 
> > > guidance in 1122.
> > >
> > > As for adding Updates 1122, this may be a good idea; I 
> don't recall
> > if
> > > RFC which includes clarifications is Informational and doesn't 
> > > Update its parent documents (RFC 4718 is the example)
> > >
> > >
> > > it's unclear what the hangup is here.  That said, I think either 
> > > way, the meaning of this document will be clear, so don't have 
> > > strong personal feelings one way or the other.
> > >
> > >
>

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sun, 5 Jun 2011 17:18:58 -0700

Michael,
    I am sometimes confused with the thinking of *some* TCPM work group
members esp., for such simple drafts(harmless drafts). Now, what if it
is a standards track document, would it be harmful to the internet? Or
if it is informational it would be considered less harmful ? I simply
don't get the point. 
    At this point I wanted to mention that we have really removed a lot
of contents like API guidance for implemenmters etc., from this draft.
The draft as it stands now is purely a clarification of RFC 1122's
persist behavior which was the original intent for which there was a
reasonable consensus. The WG members need to explain clearly why  they
are nervous about making it a standards track, FWIW, lets take the
urgent pointer clarification RFC which was recently issued (RFC 6093),
that is a standards track document. It simply clarifies the intentions
and usage of urgent pointer, and it is harmless. This document is very
similar to that, IMO.

$0.02,
-Anantha

> From: SCHARF, Michael [mailto:[email-masked]]
> Sent: Sunday, June 05, 2011 1:39 PM
> To: Anantha Ramaiah (ananth); Brian E Carpenter; Wesley Eddy
> Cc: [email-masked]; General Area Review
> Team; David Harrington
> > > >> clarifies the RFC 1122 wording. I believe the TCPM chairs and
WG
> > > group
> > > >> If it's not a Standards Track document, why is it using RFC
2119
> > > >> language?

---

From: Wesley Eddy <[email-masked]>
Date: Sun, 05 Jun 2011 23:20:38 -0400

> and usage of urgent pointer, and it is harmless. This document is very

This document contains no protocol and alters no protocol.

I don't agree with attempting any comparison with RFC 6093.  That RFC
changed the specification of the urgent pointer, whereas this
draft does not change the TCP specification one iota.

It's hard to see how Standards Track is appropriate for this draft.

I agree with Michael that "MUST" versus "must" should make little
difference to a reader; they'll get the point.

-- 
Wes Eddy
MTI Systems

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Jun 2011 15:39:12 +1200

Wes,

> This document contains no protocol and alters no protocol. 

True, but it makes a strong statement about what implementations
must do. I had a quick look, and most implementation guidelines
are Informational, although one or two (e.g. RFC 5625) are BCP.

It would be a lot clearer to a new reader if the title indicated
that it's an implementation guideline - I certainly started reading
on the assumption that it was a protocol update, which as you say,
it isn't.

I'm sure the IESG will come back with a proposed resolution.

Regards
   Brian

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sun, 5 Jun 2011 23:29:04 -0700

Hi Wes,

> This document contains no protocol and alters no protocol.

But it documents (clarifies) a protocol action namely persist condition,
FWIW.

> draft does not change the TCP specification one iota.

Fair enough.

> It's hard to see how Standards Track is appropriate for this draft.

Well, if a document updates a standards track document, then I don't see
any issues making the updating document a standards track.

> difference to a reader; they'll get the point.

Brain's point was that if we documenting an oversight then lets be
honest about it. In the same spirits, why do we want even change the
"MUST" to must.. Just to make the document informational? Beats me..

-Anantha

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 6 Jun 2011 10:40:17 -0700

Sorry about an inadvertent typo below :-

> Brain's point was that if we documenting an oversight then lets be

Should be :-

Brian's point was that, if we are documenting .....

-Anantha

> From: Anantha Ramaiah (ananth)
> Sent: Sunday, June 05, 2011 11:29 PM
> To: Wesley Eddy
> Cc: SCHARF, Michael; Brian E Carpenter; draft-ietf-tcpm-

---

From: "Borman, David" <[email-masked]>
Date: Mon, 6 Jun 2011 21:19:33 +0000

The persist document can be summed up in one sentence: Connections that are in persist (zero window probe) are no different than any other connection in established state.

When RFC 1122 was written, there existed TCP implementations that were dropping connections in persist state, treating connections that did not move forward the same as connections that weren't getting any ACKs.  RFC 1122 said, no, as long as you are getting ACK responses, the connection is still valid, and TCP shouldn't be timing out the connection.

Some TCP implementors read that as meaning that connections in persist state had to be handled specially, and swung the pendulum to the other extreme, and wouldn't drop connections in persist state even when under the exact same circumstances they would drop other connections in established state.

This ID is trying to get the pendulum back to the center.  From the perspective of the TCP protocol, as long as ACKs are being received to probes while in persist state, the connection is valid.  Other things outside the TCP protocol, such as applications or the OS, can decide to terminate any TCP connection for any reason.  An application exits.  The OS is running out of resources and decides to abort TCP connections.  Someone shuts down the computer.  There are lots of things outside of the TCP protocol that can cause TCP connections to be aborted.

This ID is not changing anything in the TCP protocol.  It is only correcting how some implementors had mis-interpreted RFC 1122, and this mis-interpretation is by no means universal.  The WG consensus was that this makes it Informational.

			-David Borman