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

[Vidhi Goel <[e-mail]>]

For all remaining issues, PR is here - https://github.com/NTAP/rfc8312bis/pull/152

Michael,
I have added some changes to replace the ambiguous “convergence” word with text that clearly states what is the impact of 0.7. 


Looking forward to hear feedback/comments.

Thanks,
Vidhi

> On Sep 8, 2022, at 8:39 AM, Vidhi Goel <vidhi_goel=[e-mail]> wrote:
> 
> Thank you Neal and Yoshi.
> 
> I will create PRs today and add you as reviewers. Will send PR links on the mailing list as well.
> 
> Vidhi 
> 
>> On Sep 7, 2022, at 10:55 PM, Yoshifumi Nishida <[e-mail]> wrote:
>> 
>> 
>> 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] <mailto:[e-mail]>> wrote:
>>> 
>>> 
>>> On Tue, Sep 6, 2022 at 7:46 PM Vidhi Goel <vidhi_goel=[e-mail] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>> 
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm