[tcpm] Cubic after RTO

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

Group,

I need some help to understand where I seem to be missing something
around RFC9438 (Cubic) and the Behavior after RTO...

   > During the first congestion avoidance stage after a timeout, CUBIC
   > increases its congestion window size using Figure 1, where t is the
   > elapsed time since the beginning of the current congestion avoidance
   > stage, K is set to 0, and Wmax is set to the congestion window size
   > at the beginning of the current congestion avoidance stage. In
   > addition, for the Reno-friendly region, West SHOULD be set to the
   > congestion window size at the beginning of the current congestion
   > avoidance stage.

Let's assume, the RTT is around 10ms, and there is one CC event every 10
RTTs - or 100ms.

Now, with the above definition, if now a chain of RTOs happen, t_epoch
is not reset at all, but may be many orders of magnitute in time in the
past, compared with the "steady state" - especially when there are a
number of subsequent RTOs with exponential backoff.

As K is also reset, the next ACK after RTO received will result in cwnd
to be calculated (by fig 1)

Wcubic(t) = C * (t - K)^3 + Wmax

With C = 0.4, K = 0, and t may be even higher than 60 sec - and not the
"normal" 0.1 sec. This results in cwnd to be set to 0.4 * 60^3 + Wmax
[segments] 86400 segments + the prior maximum cwnd - which doesn't sound
correct...


What is the linux implementation (as the baseline) actually doing after
RTO here?

Thanks,
   Richard