Re: [tcpm] finalizing CUBIC draft (chairs' view)

[Yoshifumi Nishida <[e-mail]>]

Hi Vidhi, Neal,

Thank you so much for the proposed texts.
I personally might want to add some minor updates on them, but overall they
look good to proceed.
Once pull requests have been made, I will make some comments on them to
finalize.

Thanks,
--
Yoshi

On Wed, Sep 7, 2022 at 8:50 AM Neal Cardwell <[e-mail]> wrote:

>
>
> On Tue, Sep 6, 2022 at 7:46 PM Vidhi Goel <vidhi_goel=
> [e-mail]> wrote:
>
>> Hi Yoshi,
>>
>> Thank you for summarizing the last two remaining issues.
>>
>> Point 1: TCP friendly model in the cubic draft
>>>      We can admit that the model is not valid as the paper describing
>>> the model uses some simplified presumptions.
>>>      But, it doesn't not mean the model will pose serious issues on the
>>> Internet as we haven't seen any evidence yet.
>>>
>>
>> It’s not that the model is not valid at all, but it is not very precise.
>> Copying a part of Bob’s response for this issue:
>>
>> *Summary: so far we show that the model that was used to calculate the
>> cubic_alpha value of 0.53 is not absolutely precise, but it gives equal
>> rate flows to a good approximation (within about 10% from analysis and even
>> closer in experiments over an AQM). So it is extremely unlikely that there
>> is any danger to the Internet here. Even if you believe flow equality is
>> critical, this is in the noise.*
>>
>>
>>
>> Do you think we should add some text similar to above? We can reference
>> Bob’s paper if it is already published.
>>
>
> Sounds good. A stab at some possible text:
>
> ---
> The model that was used to calculate the alpha_cubic value here is not
> absolutely precise, but analysis and simulation[1], as well as over a
> decade of experience with CUBIC in the public Internet, show that this
> approach produces acceptable levels of rate fairness between CUBIC and Reno
> flows, in practice.
>
> [1]
> https://raw.githubusercontent.com/bbriscoe/cubic-reno/main/creno_tr.pdf
> ---
>
> In addition the draft could change "which achieves the same average window
> size as Reno" to be something like "which achieves approximately the same
> average window size as Reno in many cases".
>
>
>>
>> Point 2: Multicative decrease factor during slow-start phase
>>>      We think using the current value: 0.7 may cause more packet losses
>>> in certain cases, but it can work efficiently in other cases.
>>>      We think this is a part of design choices in CUBIC as we haven't
>>> seen any tangible evidence that it can cause serious problems.
>>>
>>
>> There is text already covering this. But if you think we need to add
>> more, let us know.
>>
>> Multiplicative decrease section
>> *A side effect of setting βcubic to a value bigger than 0.5 is slower
>> convergence. We believe that while a more adaptive setting of βcubic could
>> result in faster convergence, it will make the analysis of CUBIC much
>> harder.*
>>
>> Slow start section
>> *Whichever start-up algorithm is used, work might be needed to ensure
>> that the end of slow start and the first multiplicative decrease of
>> congestion avoidance work well together.*
>>
>> Once I hear from you, I can create pull requests for these two,
>> if changes are needed.
>>
>
> IMHO these two sound like nice steps forward, and worth creating pull
> requests.
>
> Thanks, Vidhi!
>
> neal
>
>
>
>>
>> Thanks,
>> Vidhi
>>
>> On Sep 5, 2022, at 11:13 PM, Yoshifumi Nishida <[e-mail]>
>> wrote:
>>
>> Hi folks,
>>
>> We're looking for some feedback on this to finalize the CUBIC draft.
>> Based on the previous discussions, I am thinking that one way to proceed
>> is to add some explanations (not a solution!) for the points below in the
>> draft.
>> If you have some proposed texts on this point or you have different
>> ideas, please let us know.
>> If there's no opinion, I might propose some texts for them.
>> --
>> Yoshi
>>
>> On Fri, Aug 26, 2022 at 12:40 AM Yoshifumi Nishida <[e-mail]>
>> wrote:
>>
>>> Hello everyone,
>>> Based on the feedback from the last meeting, the chairs have been
>>> discussing how to finalize the cubic draft.
>>> The below is our current view on the draft.
>>>
>>> The slide for the CUBIC draft from the last WG meeting listed 4
>>> discussion points in the draft.
>>> >
>>> https://datatracker.ietf.org/meeting/114/materials/slides-114-tcpm-revised-cubic-as-ps
>>>
>>> In these items, we think that the last two points are already addressed
>>> now.
>>> With regard to the remaining two points, our views are the following.
>>>
>>> Point 1: TCP friendly model in the cubic draft
>>>      We can admit that the model is not valid as the paper describing
>>> the model uses some simplified presumptions.
>>>      But, it doesn't not mean the model will pose serious issues on the
>>> Internet as we haven't seen any evidence yet.
>>>
>>> Point 2: Multicative decrease factor during slow-start phase
>>>      We think using the current value: 0.7 may cause more packet losses
>>> in certain cases, but it can work efficiently in other cases.
>>>      We think this is a part of design choices in CUBIC as we haven't
>>> seen any tangible evidence that it can cause serious problems.
>>>
>>> We concluded this will require more detailed analysis and evaluations
>>> which can take a longer time.
>>> Based on this, we think these points are NOT needed to be addressed in
>>> the draft while it will be good to add some more explanations for them.
>>> We saw there were several opinions about documenting these points in the
>>> draft during the last meeting. If you have some suggestions here, please
>>> share your opinions.
>>>
>>> Please note that this doesn't mean we'll ignore them. we will try to
>>> publish a new version of the CUBIC draft if we find some things on
>>> them.
>>>
>>> If you have any opinions or comments on the views, please share them
>>> with us.
>>>
>>> Thanks,
>>> --
>>> Yoshi on behalf of tcpm co-chair
>>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>