Re: Why still not Cubic?

> On 6. Sep 2022, at 17:42, Scheffenegger, Richard <Richard.Scheffenegger@netapp.com> wrote:
> 
> Hi Alexander,
> 
> Until recently, the cubic implementation was more of a proof-of-concept. I believe my colleages here have made a reasonable job of addressing all the edge cases, where cubic_cc would not work properly (int overflows, etc).
> 
> However, the principle algo of the current cubic_cc was based off of an abandoned RFC draft, which only later got revived, and currently there is active IETF work to document all the algorithmic issues and improvements, which had been accumulated in Linux over the years.
> 
> In short, I would expect the current cubic_cc to make a fairly reasonable job, but it may not conform 100% to the upcoming revision of the Cubic IETF RFC. But having more exposure with cubic in main may be a reasonable idea. 
> 
> Perhaps we (#transport) should discuss changing the default cc to cubic, and maybe revert to new_reno for stable/14 when it branches?
Let us discuss this on the transport call.

I'm not sure it is a good idea to switch the default CC now on head to cubic and then, when stable/14 is branched,
back to newreno for stable/14. This would basically stop testing newreno from now on and then start testing it
in stable/14. Any changes of newreno code or any impact of other changes to newreno wouldn't be observed...

So if we switch to whatever in head, we should use it in stable/14, if the testing goes well...

Best regards
Michael
> 
> Best regards,
> Richard
> 
> 
> -----Original Message-----
> From: Alexander Motin <mavbsd@gmail.com> On Behalf Of Alexander Motin
> Sent: Dienstag, 6. September 2022 17:12
> To: Gleb Smirnoff <glebius@FreeBSD.org>; Richard Scheffenegger <rscheff@FreeBSD.org>; Randall Stewart <rrs@FreeBSD.org>
> Subject: Why still not Cubic?
> 
> NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> 
> 
> Hi guys,
> 
> Does anybody know why after so many years FreeBSD still doesn't use Cubic CC by default, relying on NewReno?  Does NewReno has some benefits or Cubic still considered experimental after so many years?  In our NAS use cases we see that while NewReno works well in data center environments with flow control and without packet losses, Cubic may work much better over WAN, WiFi and so on.  Are there known scenarios where it is worse?  Or everybody just switch to it locally?
> 
> Thanks.
> 
> --
> Alexander Motin