Re: [tcpm] Proceeding CUBIC draft

[Neal Cardwell <[e-mail]>]

On Mon, May 23, 2022 at 4:41 AM Yoshifumi Nishida <[e-mail]>
wrote:

> Hi everyone,
>
> It would be great if you could provide some feedback on this topic.
> If you just think this write-up looks acceptable, it will also be very
> helpful feedback for us.
>

Thanks, Yoshifumi. Your May 13 write-up looks quite acceptable.

I agree with Lars that we should have the draft progress as soon as
possible to be a  proposed standard.

I will note again that 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.


Again, it seems clear, IMHO, that CUBIC meets those criteria for being
named a PS.

best regards,
neal



> Also, other feedbacks such as the comments on the 8312bis draft or some
> other points are very welcome,
>
> Thanks,
> --
> Yoshi
>
> On Fri, May 13, 2022 at 1:48 AM Yoshifumi Nishida <[e-mail]>
> wrote:
>
>> Hi folks,
>>
>> Since we haven't seen any proposal for the updated texts for 8312bis
>> draft, I start drafting a write-up as a tentative alternative.
>>
>> Here's a part of the write-up related to the discussions. I guess this
>> may miss or not well describe some points of the previous discussions.
>> Please share if you have corrections or suggestions on this.
>>
>> =====
>>
>> 2: Was there controversy about particular points, or were there decisions
>> where
>>    the consensus was particularly rough?
>>
>>    This draft describes CUBIC congestion control algorithm as an updated
>> version
>>    of RFC8312.The intended status of the draft is Proposed standard while
>> the
>>    previous one is Experimental.
>>    This point raised some arguments as congestion control scheme in TCP
>> is an
>>    integral part of the Internet. The main discussion points were the
>> followings.
>>
>>
>>    1: RFC5033 provides a guideline for considering new congestion control
>> algorithms
>>       within the IETF. One argument is that the draft has not been through
>>       the process described in the guideline even though it is aiming to
>> be a
>>       proposed standard.
>>
>>       We agreed that CUBIC can basically satisfy most of the points in the
>>       guideline, however, there were some discussions whether CUBIC can
>> meet the
>>       criteria "(5) Fairness within the Alternate Congestion Control
>> Algorithm."
>>       due to the reason described below.
>>
>>       Another discussion point was how much we should follow the
>> guideline as we
>>       are not sure all previous congestion control related proposals went
>> through
>>       this process while we should treat all proposals equally in general.
>>
>>
>>    2: CUBIC utilizes TCP-friendly model for controlling transfer rate in
>> order
>>       to behave mostly fairly when it competes with Reno based algorithm.
>>       However, after some discussions, we agreed that the paper which
>> originally
>>       proposed the model has not provided convincing explanations because
>> the
>>       presumptions in the paper cannot be said to be well-suited for
>> Today's Internet.
>>
>>       On the other hand, we confirmed we don't have solid evidence that
>> the
>>       current CUBIC behaves too aggressively compared to Reno, either. We
>> also agreed
>>       the evaluations for the model will require thorough analysis which
>> may take
>>       some time.
>>
>>   As the result of discussions, we decided to publish this draft as a PS
>> doc while
>>   we will continue the discussions on these points. Some of the
>> rationales behind the
>>   decision were the followings.
>>
>>        * CUBIC has already been deployed globally for years and we have
>> not
>>          observed any reports for the dangers or potential risks in the
>> algorithm
>>          in the past.
>>
>>        * We believe there is fairly low risk that CUBIC's behavior leads
>> to
>>          congestion collapse on the Internet because CUBIC does not
>> update any
>>          of timer calculations, loss detection and timeout mechanisms in
>> TCP.
>>
>>        * As CUBIC has been widely deployed as the default congestion
>> control scheme,
>>          NewReno is becoming less used on the Internet. This may mean
>> maintaining
>>          fairness with NewReno becomes less important.
>>
>> ====
>>
>> On Thu, Apr 28, 2022 at 1:02 AM Yoshifumi Nishida <[e-mail]>
>> wrote:
>>
>>> Hi,
>>> As an option, I am thinking about putting the context for this in the
>>> write-up for the draft in case we don't have proposed texts.
>>> In this way, we can review if the write-up correctly captures the
>>> discussion points. Also, IESG might request to update the draft after
>>> reviewing it.
>>> --
>>> Yoshi
>>>
>>>
>>> On Thu, Apr 28, 2022 at 12:06 AM Lars Eggert <[e-mail]> wrote:
>>>
>>>> Hi,
>>>>
>>>> On 2022-4-19, at 11:27, Yoshifumi Nishida <[e-mail]> wrote:
>>>> > Yes, that will be very helpful. I'd really appreciate If folks who
>>>> want to add something could provide some proposed texts.
>>>>
>>>> I'll just note that we haven't seen any text proposals. *If* people
>>>> think that text should be added, please propose some?
>>>>
>>>> Otherwise we should at some point progress the document as-is.
>>>>
>>>> Thanks,
>>>> Lars
>>>>
>>>>
>>>> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>