Re: [tcpm] alpha_cubic (was: Concluding WGLC for draft-ietf-tcpm-rfc8312bis-03)

[Jonathan Morton <[e-mail]>]

> On 12 Sep, 2021, at 12:02 am, Yoshifumi Nishida <[e-mail]> wrote:
> 
> The first point is about RTT variation. 
> I think you have a point there, but I personally think the paper presumes very shallow queue so that the model can be very simple.
> In this case, we don't have to think about min or max of RTT as they will be mostly the same.
> I think we can probably argue the accuracy of the model, but I think it is too broad as a scope of this document. It looks a very deep research topic to me.
> I think the model is basically derived from Equation-based Congestion Control paper in sigcomm 2000. If we want to update or renew it, we might need another RFC5348. 
> So, I think it would be better for this doc to use the model as it is and leave its enhancements for future discussions.

I think the assumption of constant RTT will become increasingly valid as AQM is deployed, so this was a good and prescient simplification by the authors.  The alternative scenario of a relatively large drop-tail buffer can be checked empirically for reasonable behaviour, if required - but the existing wide deployment of CUBIC suggests that any serious trouble would already have been noticed.

> The second point is α in the draft might be too big. 
> During my WGLC review, I read [FHP00] once and I had similar thoughts.
> But, after I re-read the paper several times, I start having a different interpretation. 
> 
> First off, it is very clear that β=0.7 is more aggressive than β =0.5 when there's no other traffic.
> As cwnd growth is linear, if there's enough long time for the data transfer, the average cwnd for β =0.5 will be (1.0 + 0.5)/2 = 0.75 Wmax and it will be (1.0 + 0.7)/2 = 0.85 Wmax for β=0.7. 
> So, it is obvious that this model does not aim for the cases where there's no other traffic.
> 
> I believe the choice of (α,  β) in [FHP00] is designed to be more or less fair only when it competes with (α=1.0,  β =0.5)
> Hence, I think we should not apply the loss rate for no-other-traffic situation to the formula, which can lead to α3 = 0.20

That was definitely the impression I got, too, and in fact it puzzles me why anyone would assume otherwise.

Another point to note is that this entire calculation is only valid in the "compatibility" regime of CUBIC, where it is explicitly attempting to perform similarly to NewReno.  If a test scenario drives CUBIC into its "native" regime where the polynomial curve rises above the linear growth function, then it will outperform NewReno by design.  The assumption then is that NewReno is insufficiently utilising available capacity, so there is less concern over causing harm to it and more advantage to using that leftover capacity.

 - Jonathan Morton