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

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=
40ericsson.com@dmarc.ietf.org> 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 <tcpm-bounces@ietf.org> on behalf of Vidhi Goel <vidhi_goel=
> 40apple.com@dmarc.ietf.org>
> *Date: *Monday, 28. February 2022 at 20:24
> *To: *Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org>
> *Cc: *"tcpm@ietf.org Extensions" <tcpm@ietf.org>, tcpm-chairs <
> tcpm-chairs@ietf.org>
> *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=40google.com@dmarc.ietf.org> wrote:
>
>
>
>
>
> On Mon, Feb 28, 2022 at 5:07 AM Yoshifumi Nishida <nsd.ietf@gmail.com>
> 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
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>