Re: [tcpm] Proceeding CUBIC draft

[Yoshifumi Nishida <[e-mail]>]

Hi Yuchung,

it's surely one way to move forward.
But, as we had lots of intensive discussions in the past (even after 2nd
WGLC), I just would like to confirm if we're reaching the consensus.
if we still don't have any opinions even on the write-up, I am going
to move forward with it.
--
Yoshi

On Fri, May 13, 2022 at 11:01 AM Yuchung Cheng <[e-mail]> wrote:

> 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
>