Re: [tcpm] Proceeding CUBIC draft

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.
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 <ycheng@google.com> 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 <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
>>
>