[tcpm] CUBIC rfc8312bis / WGLC Issue 4

[Markku Kojo <[e-mail]>]

Hi all,

Issue 4 is lacking a separate description. Below please find some context 
for the issue 4 and description of the issue 4 as the item 3.

CUBIC has been designed to operate in two regions: 1) TCP-friendly region 
where Reno has no problem to fully utilize the available network capacity 
and 2) the "genuine CUBIC mode with concave/convex region and some 
additional details when the cwnd necessary to fully utilize the available 
capacity is large and Reno has problems to ramp up fast enough.

The intended goal for the TCP-friendly region is all correct (= behave 
equally aggressive as Reno CC) but it leaves unnoticed that there are 
several CC phases to address to behave like Reno. CUBIC only addresses 
the well-known congestion avoidance cycle. The phases the draft must 
address and justify the use of Beta = 0.7 separately:

1. CA phase: which is basically fine if only the model was correct as the 
model compensates the larger Beta (0.7) with lower alpha in the typical CA 
cycle. So, there is well argumented justification to deviate from 
Beta=0.5 in this phase but the problem of Issue 1 exists due to incorrect 
model.

The rest are CC phases in which the selection of Beta significantly 
affects the fairness of a CC algo and they are not
addressed in the current draft:

2. Slow-start phase: Beta when the sender is in slow start when
    a congestion event is signelled (Issue 2).

3. Beta when there is sudden congestion (Issue 4).
This is different from the CA phase above in item 1. In this phase the 
sender should react to congestion like Reno to take the cwnd down
quickly to resolve congestion. This often requires several consecutive 
multiplicative decreases. Using lower alpha does not compensate much 
anything here because the sender cannot continue congestion avoidance ll 
the way (close) to the previous saturation point as a new loss occurs 
earlier due to heavy congestion. This is important and all competing 
flows following the same behaviour would benefit from the corresponding 
actions of the others and congestion will be resolved quickly. Currently 
CUBIC requires roughly two times more cwnd reductions to end up with the 
same fair rate as Reno. That is, it gets unjustified benefit being slower 
to converege down.

This unfortunately would require a new heristic/algo and should be at 
least placed as a todo item in the draft (because there is need to 
decrease the sending rate consecutively several times, not just once per 
normal CA cycle, the sender should start using Beta 0.5 or even lower 
Beta to compensate the previous decrese(s) with Beta 0.7.)

This problem with CUBIC has been shown in the studies but none of those 
are cited in the current draft. SO, we have measurement data to back up 
the issue.

Thanks,

/Markku