Re: [tcpm] Proceeding CUBIC draft

[Yuchung Cheng <[e-mail]>]

On Fri, May 13, 2022 at 10:55 AM Yoshifumi Nishida <[e-mail]> wrote:
>
> Hi Yuchung,
>
> Sorry, I think I was not clear enough.
> we are waiting for the proposals for updates to 8312bis as there were some opinions about updating the draft.
> If we could have such proposals, we can discuss whether we should merge them into the draft or not. After that we can submit the draft to IESG.
>
> However, since we don't see any of them yet so far, I start worrying that we cannot move forward the doc.

Why can't the doc move forward if the list solicits diffs for a month
and does not get any??


> So, as an alternative, I am thinking if we describe the previous discussion points in the write-up, we may not need to put additional stuff in the draft before the submission.
> But, I am still wondering if this is the best way to proceed with the doc. Hence, I said this is tentative.
>
> If people have some ideas about updating the drafts, we can discuss them as well.
> --
> Yoshi
>
> On Fri, May 13, 2022 at 10:33 AM Yuchung Cheng <[e-mail]> wrote:
>>
>> 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