Cubic calculates the new cwnd based on absolute time
elapsed since the start of an epoch. A cubic epoch is
started on congestion events, or once the congestion
avoidance phase is started, after slow-start has
In transactional scenarios, it is likely that a
sender will be application limited for extended
periods of time. During this, the server only
transmits a limited amount of data, not fully
using the send window or current congestion window.
When after such a phase a subsequent larger
transfer is performed, which utilizes the full
congestion window, the cubic epoch could have
been lingering to an excessive amount of time.
Thus the next re-calculation of the cubic cwnd
would induce a massive jump of cwnd, leading to
a similar burst of sent data at line rate by
the cubic sender.
This Diff depends upon D23655, and adds the
condition of coming out from being app-limited
to again reset the cubic epoch.