Re: [tcpm] Proceeding CUBIC draft

As a co-author, I also think that we should publish Cubic as PS.

I had one comment on the write-up:
>    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.

I don’t fully understand this paragraph. Cubic behaves like new Reno for low BDPs because the cwnd is lower before a reduction event. And if Cubic ends up being less aggressive than New Reno in those low BDP environments, it simply uses New Reno congestion avoidance equation.
The language in this paragraph is a bit generic. Can you help me understand the last line and what are those presumptions?

Thanks,
Vidhi

> On May 13, 2022, at 1:48 AM, Yoshifumi Nishida <nsd.ietf@gmail.com> 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 <nsd.ietf@gmail.com <mailto:nsd.ietf@gmail.com>> 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 <lars@eggert.org <mailto:lars@eggert.org>> wrote:
> Hi,
> 
> On 2022-4-19, at 11:27, Yoshifumi Nishida <nsd.ietf@gmail.com <mailto:nsd.ietf@gmail.com>> 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
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm