Re: [tcpm] [Fwd: Confirmation for Auto-Post of I-D draft-ietf-tcpm-newcwv]

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

> >>>> I appreciate the new section on burst mitigation but why standard
> track?
> >>>>
> >>> The previous discussions on STD track centres on whether we would
> include
> >>> require a burst mitigation section, so this is now a good question.
> >>>
> >>>> The change has pro-found impact on congestion control as it
> changes
> >>>> how cwnd increases per ACK and after idle. There are a lot to
> >>>> experiment before we know this works well in real networks.
> >>>>
> >>> Are you referring to the new ack-mitigation section - requiring
> pacing
> >>> after idle?
> >>
> >> I am referring to the main changes proposed in the draft, not just
> >> pacing after idle.
> >>
> > OK, so this algorithm hasn't changed much for a couple of IETFs.
> >
> > Do you have concerns about relaxing the Standard behaviour
> (collapsing to IW
> > after one RTO), and that letting apps maintain a higher cwnd has
> dangers?
> >
> > Or do you think the algorithm may keep to high a cwnd when non-
> validated?
> >
> > Or is it something else?
> something else.
> 
> I thought standard means people have used it, found it working, and
> like how it works. May I am wrong.

A general remark...

Section 4.1.1 of RFC 2026 defines Proposes Standard as follows:

   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.

   The IESG may require implementation and/or operational experience
   prior to granting Proposed Standard status to a specification that
   materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the
   Internet.

According to the second paragraph, implementation or operational experience is formally *not* required. However, there is the third paragraph, and TCP is probably a core Internet protocol with significant operational impact on the Internet ;)

According to related past discussions, my understanding is that a large part of the TCPM community wants to have implementation and operational experience for all TCPM standards track documents. That is a high bar, and it may be one of the reasons why TCPM publishes many documents as experimental (first). (See also MPTCP as another example.)

<chair hat off>
In my personal view, publishing a proposed standard in TCPM that has low likelihood of Internet-scale deployment doesn't make a lot of sense. This is my general thinking, and it is entirely independent of this specific discussion of draft-ietf-tcpm-newcwv. 
</chair hat off>

Michael