Re: [tcpm] Cubic after RTO

[[e-mail]]

Thanks Neal!

It seems the quote could be misread to the "last" CA phase. Your
comments make it now more clear - and I need to push the t_epoch =
curtime to when cwnd first crosses ssthresh as well...

Am 22.02.2024 um 16:18 schrieb Neal Cardwell:
>
>
> On Thu, Feb 22, 2024 at 9:10 AM Scheffenegger, Richard <[e-mail]
> <mailto:[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
>
>