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

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=40cs.helsinki.fi@dmarc.ietf.org> 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
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm