Re: [tcpm] Errata RFC9438 (Cubic)

[[e-mail]]

Hi Yoshi,

Well, that probably comes down to the order in which snd_una is updated
vs. ssthresh being set - and at what stage Flight Size is calculated
during the processing of the incoming packet.

If th_ack is first updating snd_una, then the flight size calculation
would probably end up with the incorrect, deflated value.

The stack I'm familiar with does CC processing first (with the old value
for snd_una, not yet updated by th_ack, and flight size is the expected
value of 10 mss at that moment...

Capturing all that nuance would need more text; I believe the critical
aspect is to no blindly use cwnd, when adjusting ssthresh, since that
may not reflect the (expected) flight size under all circumstances, e.g.
RTO during the initial Fast Retransmission...

Hope that makes sense.

Best regards,
   Richard




Am 10.02.2024 um 12:53 schrieb Yoshifumi Nishida:
> 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=[e-mail] <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/tcpm
>     <https://www.ietf.org/mailman/listinfo/tcpm>
>