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

[Markku Kojo <[e-mail]>]

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