[tcpm] Errata RFC9438 (Cubic)

["Scheffenegger, Richard" <[e-mail]>]

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