Does the TCP CUBIC congestion control algorithm reduce window size for a connection that has been idle for a time but has not yet timed out? For example, if an application starts sending data and increases the window size above the starting value, then stops sending data for, say, 30 seconds, then resumes sending data, will the newly sent data get sent out at the same rate as what the congestion window before the first burst of data stopped would suggest, or will the TCP congestion window have been reduced during the time the connection was idle?
1 Answer
If I understand the question and scenario correctly, no it does not. It does not increase it either. According to the RFC 8312, it says:
5.8. Behavior for Application-Limited Flows
CUBIC does not raise its congestion window size if the flow is currently limited by the application instead of the congestion window. In case of long periods when cwnd has not been updated due to the application rate limit, such as idle periods, t in Eq. 1 MUST NOT include these periods; otherwise, W_cubic(t) might be very high after restarting from these periods.
Idle periods are basically ignored since they are managed by the application (ie. the user or the software) and are not a consideration in congestion control.
In real world application it would not matter anyway because TCP CUBIC is intended to return to max throughput aggressively and then have a minimal backoff period once any congestion related loss is experienced. The difference between a reduced window size due to an idle period vs. a new connection due to idle timeout of the connection flow, vs. a transient congestion event should be minimal to negligible.
