Subject: [tcpm] Intended status of draft-ietf-tcpm-newcwv - Confirmation of discussion during IETF 89

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 18 Mar 2014 10:01:29 +0000

Hi all,

In London, we had a long discussion on the TCPM charter milestone ("Decide the intended status of the document on TCP support for rate-limited traffic"). In the room there was strong consensus that this document should be heading for Experimental status, given that further experimentation and operational experience with the mechanism is needed (e.g., regarding pacing). If there are any further thoughts on this, please speak up on the list in the next two weeks.

In addition, draft-ietf-tcpm-newcwv recommends (for a long time already) to move RFC 2861 from Experimental to Historic. According to the feedback in the room, the TCPM working group seems to agree on that. This message thus intends to confirm that obsoleting RFC 2861 is consensus of the TCPM working group. Please let us know in the next two weeks if you disagree.

This message just deals with the formal status of draft-ietf-tcpm-newcwv, i.e., it is independent of the ongoing review discussions.

Thanks

Michael, Pasi, Yoshifumi

---

From: Mark Allman <[email-masked]>
Date: Tue, 18 Mar 2014 07:42:42 -0400

My high order bit here is that the newcwv document isn't in very good
shape [per previous comments] and so its a little hard to have these
conversations in that context if you ask me.  And, so I'd suggest this
arbitrary two week period is premature.

However, to give a hit on the two questions you asked ...

> In the room there was strong consensus that this document should be
> heading for Experimental status, given that further experimentation
> and operational experience with the mechanism is needed (e.g.,
> regarding pacing).

If it is the pacing that is the reason for experimental instead of
proposed I'd disagree.  Pacing makes the imposed load on the network
less aggressive than current mechanisms and so I don't see any reason to
spin at experimental.  Not that there may not be a refining of our
understanding of pacing by actually doing it, but that the possibility
of harm to the network seems pretty small to me.

Now if the reason for experimental is that newcwv is more aggressive
than the current TCP spec recommends then perhaps that is a better
reason.  However, the flip side is that we have gotten by with no
downward adjustment based on cwnd use / non-use for a long time and so
relative to that newcwv is still more conservative and hence seems fine
for proposed.

(Of course, both these are modulo that I don't really yet understand or
buy newcwv because the document has yet to convince me we need something
new and/or that the new algorithm is reasonable.  But, I do have some
trust in the involved folks and so I figure the document will probably
get there.)

> In addition, draft-ietf-tcpm-newcwv recommends (for a long time
> already) to move RFC 2861 from Experimental to Historic. According to
> the feedback in the room, the TCPM working group seems to agree on
> that. This message thus intends to confirm that obsoleting RFC 2861 is
> consensus of the TCPM working group.

I don't see this yet.  Per previous discussion with Gorry the newcwv
pertains to 'rate limited' periods, whereas RFC 2681 pertains to 'idle'
or 'application limited' periods.  The new document does not shed any
light on how these periods relate to one another.  Gorry seems to
indicate that the new version encompasses the old (and then some).  But,
I have no good understanding of this relationship myself.  I am sure I
will better grok it after the next version of the draft.  But, until we
see a cogent argument written down I don't see how we can decide whether
to obsolete RFC 2681.

Given the state of the newcwv document these questions are just
premature.  We'd be better off spending cycles on the actual meat of the
document.

allman

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 18 Mar 2014 12:20:42 +0000

> arbitrary two week period is premature.

To clarify: This is not a WGLC.

The deadline is just for those who haven't attended the meeting to speak up regarding the planned status and let us know if they have thoughts (which you did - good!). So far, we got plenty of comments that the document should be Experimental as a first step, possibly evolving to PS later. 

In the meeting, we discussed whether the document fulfills the requirements on Standards Track (RFC 2026, sec. 4.1.1):

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable, and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

In my view, a PS document on newcwv would really benefit from operational experience.

> of harm to the network seems pretty small to me.

My own concern is operational experience and the likelihood of wide adoption by TCP/IP stacks.

However, pacing specifically seems to be a concern for the community (see http://www.ietf.org/proceedings/89/minutes/minutes-89-tcpm). I just tried to summarize this briefly.

> see a cogent argument written down I don't see how we can decide

Point taken. I raise that point mainly because I have not been aware of much discussion on that so far, even if it is in the document for a long time. This can be finally discussed during the WGLC.
 
> premature.  We'd be better off spending cycles on the actual meat of

Yes, the latter is required anyway. 

Michael

---

From: [email-masked]
Date: Wed, 19 Mar 2014 12:21:01 -0000

> arbitrary two week period is premature.
In retrospect, I agree - and since the authors started an internal review,
we have found several places where language is confusing etc. Mea culpa -
we will fix, but this requires some detailed consistency checks by us.

> of harm to the network seems pretty small to me.
I think so too - In my mind we discussed if Pacing is useful (it is), if
we should recommend some of pacing pacing (I think we should, and the
draft now does). It's always going to be the case that OS implement pacing
in various ways - the big step is to say "turn it on" for these cases, I
don't see turning on as a risk.

> trust in the involved folks and so I figure the document will probably
The authors intent resonates with this.

> premature.  We'd be better off spending cycles on the actual meat of the
Again, our fault, we'll strive to do better in the next draft.

> allman
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

Gorry