Re: [tcpm] Proceeding CUBIC draft

[Yoshifumi Nishida <[e-mail]>]

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