Re: [tcpm] Errata RFC9438 (Cubic)

Hi Richard,

I am wondering about cases like this.
Say a sender sends 10 packets (cwnd=10) during slow-start and the receiver
sends back a single ack that acknowledges all packets.
Then,  hystart or hystart++ at the sender decides to exit slow-starts from
the RTT and set ssthresh.
I think flighsize will be 0 in this situation, but would it be OK?
--
Yoshi

On Fri, Feb 9, 2024 at 8:23 AM Scheffenegger, Richard <rs.ietf=
40gmx.at@dmarc.ietf.org> wrote:

> Hi,
>
> Lately I've been looking at the TCP behavior when multiple events
> overlap (e.g. RTO while loss recovery is not complete; or duplicate ACKs
> immediately after RTO before snd_nxt reaches snd_max again).
>
> I believe there is an implicit assumption in the Cubic RFC around
> cwnd_prior to track Flight Size - which does not always hold (but
> depends also on the specific implementation).
>
> RFC5681 is quite clear, that ssthresh is to be adjusted after an RTO,
> not by taking cwnd, but rather the FlightSize.
>
> The wording in RFC9438 appears to overrule this (as it updates RFC5681)
> and reverts back to how ssthresh got set prior to RFC5681, using cwnd
> directly again.
>
>
> As mentioned, cwnd does not always reliably track Flight Size (in
> particular, early on after initiating Loss Recovery, it may only be 1
> MSS). If an RTO happens and the text in RFC9438 is followed verbatim,
> ssthresh may end up being updated to cwnd * beta_cubic (0.7), instead of
> the Flight Size at this stage of Loss Recovery...
>
>
> I hope the errata, to clear up that the RFC5681 guidance as how to
> adjust ssthresh on an RTO based on Flight Size, not cwnd, is found
> useful - since it appears to me that this was clearly the intent.
>
> Best regards,
>    Richard
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>