Re: [tcpm] Proceeding CUBIC draft

[Yuchung Cheng <[e-mail]>]

Hi Yoshifumi,

Thanks for your time to get the doc to move forward. Are you proposing to
draft a diff for 8312bis, or something else. I don't quite parse what you
mean by "drafting a write-up as a tentative alternative"?

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
>