Re: [tcpm] Cwnd growth after fast convergence in CUBIC

+Lars and ICCRG

Hi Wesley,

I had noticed the same problem as you described when I implemented Cubic. This is my take on computing the K factor that avoids the situation of target cwnd <= cwnd.

W_max = cwnd = 100
Cwnd = cwnd * beta = 70 

W_max = W_max * 0.85 = 85

I simplified the formula to calculate K as below:

K = cbrt(W_max*(1-beta)/C)
=> K = cbrt(W_max - W_max * beta) / C)

// As I already computed cwnd = Wmax * beta, I replace it by cwnd (without the convergence factor)
=> K = cbrt(W_max - cwnd / C)

This ensures that the target cwnd is never below 70. 

IMO, we should not be applying beta to W_max after convergence factor has been applied in the K formula. Perhaps, it was an oversight in K’s formula.

Thanks,
Vidhi

> On Nov 5, 2020, at 11:32 AM, Rosenblum, Wesley <wesleyr=40amazon.com@dmarc.ietf.org> wrote:
> 
> 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
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm