Re: [tcpm] Proceeding 8312bis draft (Re: 2nd WGLC for draft-ietf-tcpm-rfc8312bis)

[Gorry Fairhurst <[e-mail]>]

I support publication as PS, and I'd like to see areas of study to be 
identified where possible.

With a separate RFC to understand the topics to studied and how to 
improve the spec.

A while ago, I stepped back from further commenting on how 8312bis 
relates to other IETF drafts not through technical indifference, but 
because I saw it as important to have an RFC that relates to the 
currently deployed CUBIC. I'd be keen to rejoin this if we can figure 
out how to publish and progress.

Best wishes,
Gorry.


On 02/03/2022 20:12, Martin Duke wrote:
> Wearing no hats, I also support publication as PS. Quite aside from 
> legalistic arguments about what's in certain RFCs, it's self-evident 
> that Cubic has much wider deployment experience than nearly anything 
> else that we've granted Proposed Standard status.
>
> On Tue, Mar 1, 2022 at 2:55 AM Mirja Kuehlewind 
> <mirja.kuehlewind=[e-mail]> wrote:
>
>     In case that helps, +1 to publish as PS. We already discussed this
>     in length when we made the decision to go for PS. Cubic is widely
>     deployed (and didn’t break the Internet) and publishing as PS
>     reflects this reality.
>
>     I think it also is important to document known limitation or
>     short-comings of Cubic such that future congestion control
>     research can take them into account accordingly. However, I don’t
>     believe people are planning to explicitly do further
>     experimentation with Cubic (rather than developing new schemes
>     instead).
>
>     Mirja
>
>     *From: *tcpm <[e-mail]> on behalf of Vidhi Goel
>     <vidhi_goel=[e-mail]>
>     *Date: *Monday, 28. February 2022 at 20:24
>     *To: *Neal Cardwell <ncardwell=[e-mail]>
>     *Cc: *"[e-mail] Extensions" <[e-mail]>, tcpm-chairs
>     <[e-mail]>
>     *Subject: *Re: [tcpm] Proceeding 8312bis draft (Re: 2nd WGLC for
>     draft-ietf-tcpm-rfc8312bis)
>
>         I would argue for:
>
>         (2) publish the 8312bis draft as a PS doc, and
>
>         (2b) publish an additional doc that describes any aspects of
>         CUBIC where the community would like to see further
>         experiments or improvements.
>
>         IMHO Michael Scharf made an excellent argument for PS status
>         for CUBIC on Feb 22 (
>         https://mailarchive.ietf.org/arch/msg/tcpm/k47hlSsx1lRupy5LRTJ5pQ6LrDE/ )
>         by simply quoting a definition of PS from RFC 7127:
>
>     I agree with Neal’s suggestion based on PS status definition from
>     the above RFC.
>
>     Thanks,
>
>     Vidhi
>
>
>
>         On Feb 28, 2022, at 6:29 AM, Neal Cardwell
>         <ncardwell=[e-mail]> wrote:
>
>         On Mon, Feb 28, 2022 at 5:07 AM Yoshifumi Nishida
>         <[e-mail]> wrote:
>
>             Hi,
>
>             We've been discussing how to proceed 8312bis draft, but I
>             think we still haven't settled yet.
>
>             In my understanding, there seems to be the following
>             options so far.
>
>             if you have some thoughts on them or you have other
>             options for this, please share.
>
>             BTW, please note that this discussion might affect our
>             future drafts because we want to apply the same bar for
>             all standard docs as much as possible.
>
>             1: Publish the draft as a non-standard doc
>
>             a: publish as an informational doc
>
>             b: publish as an experimental doc
>
>             * we might need to describe what experiments are expected.
>
>             2: Publish the draft as a PS doc
>
>             a: do additional experiments to make sure there's no
>             concern as a PS doc.
>
>             * we will need to decide what kinds of experiments are
>             required, what would be the expected results before the
>             experiments.
>
>             * we need to delay the publication of the doc until the
>             validation of the experiments has finished
>
>             b: publish an additional doc that describes the checking
>             points on the doc (and other related docs) for long term
>             analysis.
>
>         I would argue for:
>
>         (2) publish the 8312bis draft as a PS doc, and
>
>         (2b) publish an additional doc that describes any aspects of
>         CUBIC where the community would like to see further
>         experiments or improvements.
>
>         IMHO Michael Scharf made an excellent argument for PS status
>         for CUBIC on Feb 22
>         (https://mailarchive.ietf.org/arch/msg/tcpm/k47hlSsx1lRupy5LRTJ5pQ6LrDE/)
>         by simply quoting a definition of PS from RFC 7127:
>
>             A Proposed Standard specification is stable, has resolved known
>
>             design choices, has received significant community review, and
>
>             appears to enjoy enough community interest to be considered valuable.
>
>           
>
>             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.
>
>           
>
>             A Proposed Standard will have no known technical omissions with
>
>             respect to the requirements placed upon it.  Proposed Standards are
>
>             of such quality that implementations can be deployed in the Internet.
>
>             However, as with all technical specifications, Proposed Standards may
>
>             be revised if problems are found or better solutions are identified,
>
>             when experiences with deploying implementations of such technologies
>
>             at scale is gathered.
>
>         It seems clear, IMHO, that CUBIC meets those criteria for
>         being named a PS.
>
>         best regards,
>
>         neal
>
>         _______________________________________________
>         tcpm mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/tcpm
>         <https://www.ietf.org/mailman/listinfo/tcpm>
>
>     _______________________________________________
>     tcpm mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/tcpm
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm