From nobody Tue Sep 06 19:12:43 2022 X-Original-To: freebsd-transport@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MMZlg5Jvkz4bT73 for ; Tue, 6 Sep 2022 19:12:47 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MMZlg17WFz3dq6; Tue, 6 Sep 2022 19:12:47 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:196b:3ddd:86ee:cfac]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id D30FF71E33506; Tue, 6 Sep 2022 21:12:43 +0200 (CEST) Content-Type: text/plain; charset=us-ascii List-Id: Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-transport List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-transport@freebsd.org X-BeenThere: freebsd-transport@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: Why still not Cubic? From: tuexen@freebsd.org In-Reply-To: Date: Tue, 6 Sep 2022 21:12:43 +0200 Cc: Alexander Motin , Gleb Smirnoff , Richard Scheffenegger , Randall Stewart , "" Content-Transfer-Encoding: quoted-printable Message-Id: <55783005-52D7-4EFE-87DF-766B9AC70F6F@freebsd.org> References: To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4MMZlg17WFz3dq6 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 193.175.24.27 is neither permitted nor denied by domain of tuexen@freebsd.org) smtp.mailfrom=tuexen@freebsd.org X-Spamd-Result: default: False [-1.69 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.995]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_LOW(-0.10)[193.175.24.27:from]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-transport@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_NO_DN(0.00)[]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; FREEFALL_USER(0.00)[tuexen]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N > On 6. Sep 2022, at 17:42, Scheffenegger, Richard = wrote: >=20 > Hi Alexander, >=20 > 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). >=20 > 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. >=20 > 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.=20 >=20 > 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 >=20 > Best regards, > Richard >=20 >=20 > -----Original Message----- > From: Alexander Motin On Behalf Of Alexander Motin > Sent: Dienstag, 6. September 2022 17:12 > To: Gleb Smirnoff ; Richard Scheffenegger = ; Randall Stewart > Subject: Why still not Cubic? >=20 > 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. >=20 >=20 >=20 >=20 > Hi guys, >=20 > 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? >=20 > Thanks. >=20 > -- > Alexander Motin