Re: [tcpm] CUBIC rfc8312bis / WGLC Issue 6 and proposed text

[Vidhi Goel <[e-mail]>]

Thanks Yuchung.

I agree that we don’t need rwnd check and we already mention about using rfc7661 for when app sends are smaller than cwnd. I will review what is missing in the draft from Markku’s text.

Vidhi

> On Jul 12, 2022, at 7:46 PM, Yuchung Cheng <ycheng=[e-mail]> wrote:
> 
> AFAIK, the latest (and previous) Linux Cubic implementation does not follow
> "The implementations that use _cwnd_ MUST use other measures to avoid
> _cwnd_ from growing beyond the receive window"
> 
> I don't see the need to add that check in Linux as the effective
> window is always the min of cwnd and rwnd.
> 
> On the other hand, Linux does restrict cwnd growth if flight size is
> below cwnd but the
> actual logic is more sophisticated than a "cwnd < inflight" check to
> work w/ TSO chunking issue well.
> https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_output.c#L1881
> (Neal cc'd here is the inventor of the advanced check)
> 
> Just want to reflect a major implementation status.
> 
> 
>> On Tue, Jul 12, 2022 at 2:01 PM Vidhi Goel
>> <vidhi_goel=[e-mail]> wrote:
>> 
>> Thank you Markku for proposing the text. Some of this is already covered in the latest draft but I can do some edits to your proposed text and create a PR.
>> I spoke to other co-authors about this suggestion as well and we are mostly ok with it.
>> 
>> 
>> Vidhi
>> 
>>>> On Jul 11, 2022, at 5:37 PM, Markku Kojo <kojo=[e-mail]> wrote:
>>> 
>>> Hi all,
>>> 
>>> I promised to propose some text to some of the remaining issues.
>>> This thread starts the discussion on the issue 6 and proposes text to solve the issue:
>>> 
>>> Issue 6) Flightsize:
>>> 
>>>  The current text in Sec 4.6 w.r.t using FlightSize vs. cwnd for
>>>  calculating multiplicative decrease is fine except that it does
>>>  not quite correcly reflect what stacks that use cwnd instead of
>>>  flightsize should do and actually do. AFAIK and what was
>>>  discussed in github all stacks apply some sort of restrictions
>>>  to not allow cwnd to grow beyond rwnd and to not use an
>>>  arbitrarily high (old) cwnd value to calculate new cwnd
>>>  when a congestion event occurs.
>>> 
>>> 
>>> Current text in Sec 4.6::
>>> 
>>> Some implementations of CUBIC currently use _cwnd_ instead
>>> of _flight_size_ when calculating a new _ssthresh_ using Figure 5.
>>> 
>>> Proposed new text:
>>> 
>>> Some implementations of CUBIC currently use _cwnd_ instead
>>> of _flight_size_ when calculating a new _ssthresh_ using Figure 5.
>>> The implementations that use _cwnd_ MUST use other measures to
>>> avoid _cwnd_ from growing beyond the receive window and to not
>>> allow _cwnd_ to grow when bytes in flight is smaller than
>>> _cwnd_. This prevents a CUBIC sender from using an arbitrarily
>>> high _cwnd_ value in calculating the new value for _ssthresh_
>>> and _cwnd_ when a congestion event is signalled, but it is not
>>> as robust as the mechanisms described in [RFC7661].
>>> [Many|Most|All] TCP implementations of CUBIC that use _cwnd_ apply
>>> such measures. Likewise, a QUIC sender that also uses congestion
>>> window to calculate a new value for the congestion window and
>>> slow-start threshold is required to apply similar mechanisms
>>> [RFC 9002].
>>> 
>>> 
>>> Any comments and help in formulating the text are welcome.
>>> 
>>> Need also some guidance from TCP implementations of CUBIC to finish up the second but last sentence.
>>> 
>>> Thanks,
>>> 
>>> /Markku
>>> 
>>> _______________________________________________
>>> tcpm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>> 
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm