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

[Mirja Kuehlewind <[e-mail]>]

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]<mailto:ncardwell=[e-mail]>> wrote:


On Mon, Feb 28, 2022 at 5:07 AM Yoshifumi Nishida <[e-mail]<mailto:[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