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

["Scharf, Michael (Michael)" <[e-mail]>]

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

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.

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

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.

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

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

Yes, the latter is required anyway. 

Michael