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

[Markku Kojo <[e-mail]>]

Hi Yuchung,

On Tue, 12 Jul 2022, Yuchung Cheng 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.

That does not help. If cwnd is allowed to grow way beyond rwnd (more than 
43% for CUBIC or more than 100% for Reno CC), a sender would not respond 
to an arriving congestion signal effectively at all (and may even 
increase the cwnd). That is against the very basic rule in congestion 
control principles we have.

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

I'm not sure I follow your logic. Doesn't that effectively restrict cwnd 
from growing beyond rwnd? To my understanding with that check Linux 
applies "other measures to avoid _cwnd_ from growing beyond the receive 
window". It does not matter whether the conncetion is 
receiver-application limited via rwnd or sender-application limited. If 
rwnd limits flight size, cwnd will not grow more. Maybe I am missing 
something?

Thanks,

/Markku

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