Re: [tcpm] Proceeding CUBIC draft

Hi Vidhi,

Yes, the sentences might be too simplified, but I didn't want to add very
detailed explanations of the analysis for TCP friendly models.
I think the points of the discussions was whether TCP friendly model used
in the draft was valid because it is used to decide alpha and beta value.
I think Markku's e-mail (
https://mailarchive.ietf.org/arch/msg/tcpm/bds-h_a6-NliTjx-ZqUSaFpSSnA/)
and Bob's paper linked
in the mail explained the points well.
Rather than describing them in the write-up, I just tried to explain the
presumptions used for the model works with shallow FIFO queue, which
was generally acceptable when CUBiC was designed. But, we might need
more investigation for the impacts when we apply it to today's complex
networks.

But, in any case, it seems that we are inclined to add some more texts in
the draft (which is good!). In this case, I will make the write-up simpler
than this.

Thanks,
--
Yoshi

On Tue, May 24, 2022 at 11:00 AM Vidhi Goel <vidhi_goel@apple.com> wrote:

> 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>
> 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> wrote:
>>
>>> Hi,
>>>
>>> On 2022-4-19, at 11:27, Yoshifumi Nishida <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
>
>
>