Re: [tcpm] Cubic after RTO

[Neal Cardwell <[e-mail]>]

On Thu, Feb 22, 2024 at 9:10 AM Scheffenegger, Richard <[e-mail]>
wrote:

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

In the RFC and in the Linux TCP CUBIC code, t_epoch *is* reset. :-) Note
that the RFC says:

"t is the elapsed time since the beginning of the current congestion
avoidance stage"

The CUBIC curve is only used during the congestion avoidance stage, meaning
cwnd > ssthresh. And this "t is the elapsed time since the beginning of the
current congestion avoidance stage" means that basically t_epoch (where per
the RFC t_epoch is "The time in seconds at which the current congestion
avoidance stage started") is set to "now" every time that the connection
enters congestion avoidance (meaning cwnd cross above ssthresh).

That means that there is no concern with multiple RTO recoveries causing
t_epoch to be far in the past. Because t_epoch is set to "now" every time
the connection crosses into congestion avoidance and starts using the CUBIC
curve computation to set the cwnd.

That's how the Linux code works as well. Every time there's a fast recovery
or RTO event, Linux TCP CUBIC sets ca->epoch_start to 0 (code link
<https://elixir.bootlin.com/linux/v6.7/source/net/ipv4/tcp_cubic.c#L346>).
Then, when in congestion avoidance, when CUBIC seesca->epoch_start is 0 (code
link
<https://elixir.bootlin.com/linux/v6.7/source/net/ipv4/tcp_cubic.c#L235>),
it sets ca->epoch_start = tcp_jiffies32, meaning it sets t_epoch to now.

best regards,
neal




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