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

[Yuchung Cheng <[e-mail]>]

On Thu, Jul 14, 2022 at 4:12 PM Markku Kojo
<kojo=[e-mail]> wrote:
>
> 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?
That's right. Limiting cwnd growth on flight size automatically
prevents cwnd goes far beyond rwnd for the congestion case you are
concerned about.

Your suggested text "The implementations that use _cwnd_ MUST use
other measures to avoid _cwnd_ from growing beyond the receive window"
is easily interpreted as a line of code "cwnd = min(cwnd, rwnd)"

What I am saying is that this sentence is not necessary and overly
strict. Limiting cwnd growth based on inflight which is based on the
effective sending window (= min(cwnd, rwnd)) already prevents cwnd
bloats over rwnd. I don't see why Cubic needs to have more strict
rules than other C.C.s.

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