tcp: cubic - restart epoch after RTO

[rscheff]

Summary

Per RFC9438, sec 4.8, t_epoch is supposed to remain
the time since the current congestion avoidance
phase - presumably prior to the RTO.

However, doing so will result in an extremely inflated value
when ACKs are processed, since the RTO may be many orders of
magnitude higher than a typical RTT (e.g. 15 sec vs 0.1 ms),
especially when there are multiple RTOs with exponential
backoff after another.

In that case, cwnd can jump to exteme values with the
next received ACK - up to the full receive window, and
TSO can burst massive traffic into the network.

Test Plan

use siftr to monitor the evolution of cwnd across
a longer period of packet discards; once slow-
start is over, cwnd jumps up dramatically.

[tuexen]

Is the patch inline with the comment from Neal on the TCPM mailing list?

[cc]

Good catch! Always keep an eye on the cubic_data->t_epoch refresh.

[rscheff]

I suspect this is not the final patch, but suffices for now to stop excessive inflation of cwnd on the first ACK when transistioning from slow-start to congestion avoidance.
The guidance given was that t_epoch should be reset at the time cc transitions from slow-start to cong-avoidance.
However, I would like to revisit this anew, once the major overhaul in D41715 is in...