[tcpm] Cwnd growth after fast convergence in CUBIC

["Rosenblum, Wesley" <[e-mail]>]

In RFC8312, section 4.6, the fast convergence heuristic specifies to further reduce W_max when a decrease in available bandwidth is detected. After W_max has been further reduced, W_cubic(0) will be less than cwnd, since W_max is now less than the previous cwnd. When entering congestion avoidance, this can cause the target congestion window to be less than the current congestion window. For example, say cwnd = 100, beta_cubic = .7 and a congestion event occurs:

W_max = cwnd = 100;
W_max = W_max*(1.0+beta_cubic)/2.0 = 85   // further reduce W_max for fast convergence

cwnd = cwnd * beta_cubic = 70	          // window reduction
W_cubic(0) = W_max * beta_cubic = 59.5

If we were to enter congestion avoidance at this point, with a small enough RTT, the target candidate congestion window as calculated by W_cubic(t+RTT) may be less than the current congestion window (~59.5 < 70). 

My question is: How should the cwnd be adjusted in congestion avoidance when it is below the target candidate congestion window? If we were to follow section 4.3 and increment cwnd by (W_cubic(t+RTT) - cwnd)/cwnd, this would result in a negative increment, which doesn’t make sense to me. The Linux CUBIC implementation adds a “very small increment” in such a case: see https://github.com/torvalds/linux/blob/master/net/ipv4/tcp_cubic.c#L293-L297. Does anyone know why Linux adds that increment? My inclination is to just leave the cwnd as is and not make any adjustment when target cwnd <= cwnd, but I’m wondering if there is any other guidance for this case.

Thanks,
Wesley