From nobody Tue Sep 06 18:02:33 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 4MMYBk0zJdz4cKhD for ; Tue, 6 Sep 2022 18:02:38 +0000 (UTC) (envelope-from Cheng.Cui@netapp.com) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2040.outbound.protection.outlook.com [40.107.93.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MMYBh2tclz3XNZ; Tue, 6 Sep 2022 18:02:36 +0000 (UTC) (envelope-from Cheng.Cui@netapp.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nu3Lk0WVe3sf0Upy8cYeLcCc/m884es2nTM4rwa4sCaXKtuqp0eKxfLrUJzZChUzkIUiEi0y/Km6XetEUmUZ1bc7nzelrla/Wl/dgY1k4mzxN5UB07oTGgV5SxxM3MlveCO2y9kDH3Q5cRSGBvcWRrKTrXQp52CFSlVw0WLdJASpvishjmaEIc27VtJnWx1vnqyKGRGurFT1/vuCJAyjvXhTQR8CgMR72S+eCAv/oERejpborYeA8FRdgLPg63Wbvyqu5GJUX8pk3xBKAu+VxHtq1iZMv2wIkSPPuYqf2lfe+r+TcLxgEihShtDv9flSG+XBSM5pPws9TWccpXqklQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PoqtfJLRfBRTFLW7t5vSsRg39sw4Ip9hY2lRbrZUlxs=; b=HL7hC/f7ZYVP5zYVeoIDpjcwwfvdbsINzFPrBPa4PjkmELql4gjKQ+x/znPAqem4/GeWq8yyk5X/HIIbk+NoEPFxjtdw7ZbkpxgXzzgI9egoV+UZ4gNA7DGi9L+6H/oGI+D4kaBAxH9tVOagdTD/TfRZo/OcSRIFuv1VY29ctfdl8NsjVp7gC83u5iRZm1mI2jSfNy4dyU+hgIe7IfywV4bh5WNZELYH5D5DHzPK/e2bugpK2DOHd94gIYAogYo7K2kL6JB6VJ2T4tZvYav1rvC0qJHLfkKOcGy1MaAvsmJ0F+sdDD2qLehmbCSTV7r271gqFjldHmvP3vW69gapYw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=netapp.com; dmarc=pass action=none header.from=netapp.com; dkim=pass header.d=netapp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PoqtfJLRfBRTFLW7t5vSsRg39sw4Ip9hY2lRbrZUlxs=; b=lJjqByt+aJHqw7aaTwjQpSzkD7bLKD/XP96TuzKOXy7rqKLuqGXDWVdwsda/CzaHQ9teFMCM5nQ+19mJoFr4iTLmQzlJcJBfgSao1skrqJCthYh6g66B8sBLkJ7VwSKnoAgE0l6+JAx3A+A5fY/H+X/QD2+JKof8QIPw+jq01zEroqecBlAOwwFb0fm2lBcwBGGBDuFLvwc2OxPGRV6oMamdpVquAKqACmqMoMoZHWdi6elpd4fff/dOO8N633d3AxRf3tVa5EqWhn87TyjaqwASJGoyJtH+8QeY/zps6lPO+js+5Na8uP9LOVHdNzWbD+VGp3rhQc00bo7ozJlqNg== Received: from MN2PR06MB6237.namprd06.prod.outlook.com (2603:10b6:208:de::11) by PH0PR06MB7096.namprd06.prod.outlook.com (2603:10b6:510:24::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5588.10; Tue, 6 Sep 2022 18:02:34 +0000 Received: from MN2PR06MB6237.namprd06.prod.outlook.com ([fe80::313f:3621:2524:d94]) by MN2PR06MB6237.namprd06.prod.outlook.com ([fe80::313f:3621:2524:d94%5]) with mapi id 15.20.5588.018; Tue, 6 Sep 2022 18:02:34 +0000 From: "Cui, Cheng" To: "Scheffenegger, Richard" , Alexander Motin , Gleb Smirnoff , Richard Scheffenegger , Randall Stewart CC: "" Subject: Re: Why still not Cubic? Thread-Topic: Why still not Cubic? Thread-Index: AQHYwgMXy2j074q/d0KP0wEXr4Sbyq3SiThQgAAkfTk= Date: Tue, 6 Sep 2022 18:02:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 99efbaef-41d7-4f79-f1d7-08da9031f976 x-ms-traffictypediagnostic: PH0PR06MB7096:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CscpEr28ymNc6SECYzGvuVJHVbGPjuzDy9McB9Z9OyIqDYn5EMncNTgseUuLs+hxt3VEAR5zhimnSutGO6qOA6JR7R7Z32IHwfiircy06lwG2Mx1Nx+Ara+m49ZKJqVNDZdFexXWnq0mOHsamNHjSlb3e3tTyUItE1mtp6rmrvgKkc/b8KJ+jpOty6rL/y9KuZtbDA5atbtdo5KSOhUOZEo1M/LvmV8CT3OeDfObSKtV5wFqVJ1abYychMMxlsttNokcQF8AfmgBCHDxrgOqMaYmkyr5hLB7+VHtHSBB2bdRkZ3SH2dfxa1HK0eAAMrCF9xtMftJkwgNLkVv61FxHnf1bz4CStu044CaEfHaXPfJow++4k/Hn0d9+HaiIX/BM1MG6FQJuNv85gg46CvwRC0T0D533g0UT7M3nCa3slXGO1J/6s0mxCPl0I0dIXUWTtedyrctbXpOe9qxOMUF93ZJG6c5l3vvEyuYuvp6OeIz5JlJKwRM7teYsieRmwqcIHTHcBn/pYD20vs7Wh7OMzm0xTgoHJHPKeVai1azzM5l7PGdX8ranqKW5tOTL96ANEvKfaaq/XeALEG2E69AP/F6DepSfDx6Kol7wtGT1sh3wspQb+pf+fyBMjEZdI/p5OmpJfJ6yt5w5PwsSWV4TLnZVbp6s6Q9NSAPFwrT9Ssr8e/4kLi4ckefxfCiu0uoO2nfrttPLEqhbbYtqNwZxc8hh0+nGkxs4uAB1PPPaemDoxVmzzIkzf+P3HqVTsZjfJ7SQ/6AneY6pU3Yy+42yKGYCx0Na044+4pAGegujm7fAXwK47YmUtCOek+jJUAgHpLMSEr/nh+E8aZBMH3Vlg== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR06MB6237.namprd06.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230016)(4636009)(346002)(366004)(396003)(39860400002)(376002)(136003)(186003)(166002)(71200400001)(110136005)(316002)(3480700007)(38100700002)(33656002)(53546011)(7696005)(38070700005)(55236004)(8936002)(55016003)(6506007)(52536014)(86362001)(41300700001)(76116006)(83380400001)(478600001)(966005)(2906002)(4326008)(122000001)(450100002)(8676002)(66946007)(26005)(66556008)(66476007)(5660300002)(66446008)(9686003)(64756008)(15398625002);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?U0W+/FpmjO3z7vXB6hJ5ymW/AeIaoHi0/7jaq00G/Fy4UjjJjA8T7CTK?= =?Windows-1252?Q?T9yuCnHVrXT7LFgOYJCC5BhcJLePurAaARLqAlHi4cBvBIFWlmbK2iJ9?= =?Windows-1252?Q?dWLIc2RU29ZZ8IBk7qu3K3pWQa4LDk/38SVxjcUMiC292HED211y89XZ?= =?Windows-1252?Q?PdMrEOR7uWMBAbgwSDaowa1KhUEK9G7gsCo/fgk5BnRU0GY1YWk4/nQh?= =?Windows-1252?Q?0FUAQYNh6gaPgnuO0UDOBkBx8NeYMo814QKZ0DEHSrpDOacllu7irzZC?= =?Windows-1252?Q?iXiC0zJrzdTBsNfCnEd3hyWvYN8tnQZ11nLrQRXaxje5HIvquDOiBdo0?= =?Windows-1252?Q?wUOV6YnPOPJvtTL3iwjuwm7n3SazcKUMYC+XJ7FmYFnX8MJrvQS574Gv?= =?Windows-1252?Q?QHzPTzdFVw9JcA+qILcxhQSWL4ztaG0fQp5NMLJZNBThs3gg4XPYQQeq?= =?Windows-1252?Q?4FnxJehIgkvSzbl3LQM4U50XxuGqUjIPjM16cP9UO0I6fmmBH0UC5f5K?= =?Windows-1252?Q?l3LzupPuS9h6DY/GGpu3gErDjo0mXOu+WJPWA1GkFct8ydjeqNz7wBOC?= =?Windows-1252?Q?Vdu8q7vG5VziVZ31k5kjmVXD9lcgPui8ikOTp5Z9k+Y/vZP3wP0knFHP?= =?Windows-1252?Q?L5Q7Gd/OmpAq7XBa+qmFC1DjkNo0R5AmlGdKS+Wo8mcXawP62lremmgc?= =?Windows-1252?Q?PUWUej4kvhuOW/sLHcomqBaEf85PUuIsCmORGaER+Vh6Nou3qoOHeDlp?= =?Windows-1252?Q?4EuXFqixBRufWh2+4Z3jwfQIkB29VDAPMH9RdryI5wrQcpfQHwBXVNE+?= =?Windows-1252?Q?w/Qb1wAzlJihFTcT25A9BHuIczkUDQRE1flDT3OHrGzutWox7gFuV7bW?= =?Windows-1252?Q?SrONMyXo6StYhHuA6S6V+7p02UiElXlho0krQX/uLsauqCP9ORIP9D9f?= =?Windows-1252?Q?RJ7aglDskYYcu+p+EYE9kmgVGuzvq32Pua/Ow3d9vl0xiE0sVKtl6VyM?= =?Windows-1252?Q?FYBq7ngtLEeQF+3nd0t7yHBRziRw3uYhnMV8BzJ1umSSRfZtwGd7zBoH?= =?Windows-1252?Q?ZwtJ2zqS2oKcu20rJ9I5RqL6/WvwYX4edWVBVJkSEvRXg/kZSa3CvmPp?= =?Windows-1252?Q?I/RZSxxxILs9jaigJXT7BwgWrVNcg/chIMXrzFsepvvOE14OmmxnXidk?= =?Windows-1252?Q?2jFZL/4i1NJyPEd5dDX3TBlkoEC8I6LjhmhZCCuBR9jQbI4l6+bXotwP?= =?Windows-1252?Q?1VhbZcIt1QDlsNJKV4yNRGUz0CIL31YLnb/GWWXZJY0EvtJ8/2rQwgtT?= =?Windows-1252?Q?mcFaOWXBDviGoLWvZ7/qSfgJ313RE6wZKDDHJeJluoYP3LP0O0JOG/IW?= =?Windows-1252?Q?A5rAUwcFfhXG+ZomegwZWxeVisB1pCQpPeDH3tcrNaDQg8v73DAPCdB2?= =?Windows-1252?Q?KCN2IgaAG4Jt53GkaN+EZ/5K12446fP2npVKK+mEksqCjfZ1M7Uq3SkY?= =?Windows-1252?Q?gds+zQl6O3SsIfi6/qVoHxnk0uYZjPj3cOC+AkkmsGlb00Jir3tupmfX?= =?Windows-1252?Q?YznS1OVFz2u1IfYEIjnd/9qOWYvjG/9z+FQafA5278mCcAyGwpnEY19E?= =?Windows-1252?Q?KYaiAhdGev1w06gZzKQOgpu8TWSRZnZxn+v3kI/CuBoOTKED3ao2BtTT?= =?Windows-1252?Q?YpS536SPafywkuegRzH03FTTVAhfANN6r6QFxVhyxyvnaeQc6mEX8w?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_MN2PR06MB6237B14D402EDA43329218719D7E9MN2PR06MB6237namp_" 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 X-OriginatorOrg: netapp.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR06MB6237.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 99efbaef-41d7-4f79-f1d7-08da9031f976 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2022 18:02:33.8996 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: cw9ZTlPXQDadYRWJNQLrqLFxyMEViSdIBETc9THSMj3vvimke/sZs4O45HP2OcG1/dJ2Cty0Eb7f5Bcac3989g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR06MB7096 X-Rspamd-Queue-Id: 4MMYBh2tclz3XNZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=netapp.com header.s=selector1 header.b=lJjqByt+; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=quarantine) header.from=netapp.com; spf=pass (mx1.freebsd.org: domain of Cheng.Cui@netapp.com designates 40.107.93.40 as permitted sender) smtp.mailfrom=Cheng.Cui@netapp.com X-Spamd-Result: default: False [-4.79 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; DWL_DNSWL_LOW(-1.00)[netapp.com:dkim]; NEURAL_HAM_SHORT(-0.99)[-0.993]; NEURAL_HAM_MEDIUM(-0.95)[-0.948]; NEURAL_HAM_LONG(-0.85)[-0.852]; DMARC_POLICY_ALLOW(-0.50)[netapp.com,quarantine]; R_DKIM_ALLOW(-0.20)[netapp.com:s=selector1]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-transport@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_IN_DNSWL_NONE(0.00)[40.107.93.40:from]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; HAS_WP_URI(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[netapp.com:+]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.93.40:from] X-ThisMailContainsUnwantedMimeParts: N --_000_MN2PR06MB6237B14D402EDA43329218719D7E9MN2PR06MB6237namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > Perhaps we (#transport) should discuss changing the default cc to cubic, = and maybe revert to new_reno for stable/14 when it branches? Agree with Richard to make cubic as default. Since the recent improvements = in cubic (below), the use at my side didn=92t show much problem. Perhaps ma= king it default will draw further improvement/optimization. https://freebsdfoundation.org/wp-content/uploads/2021/05/TCP-Cubic-is-Ready= -to-Take-Flight.pdf -- Cheng Cui From: owner-freebsd-transport@freebsd.org on behalf of Scheffenegger, Richard Date: Tuesday, September 6, 2022 at 11:43 AM To: Alexander Motin , Gleb Smirnoff ,= Richard Scheffenegger , Randall Stewart Cc: Subject: RE: Why still not Cubic? NetApp Security WARNING: This is an external email. Do not click links or o= pen attachments unless you recognize the sender and know the content is saf= e. 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 aba= ndoned RFC draft, which only later got revived, and currently there is acti= ve 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 j= ob, 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, an= d maybe revert to new_reno for stable/14 when it branches? Best regards, Richard -----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? NetApp Security WARNING: This is an external email. Do not click links or o= pen attachments unless you recognize the sender and know the content is saf= e. Hi guys, Does anybody know why after so many years FreeBSD still doesn't use Cubic C= C 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 co= ntrol 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 --_000_MN2PR06MB6237B14D402EDA43329218719D7E9MN2PR06MB6237namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

> Perhaps we (#t= ransport) should discuss changing the default cc to cubic, and maybe revert= to new_reno for stable/14 when it branches?

 

Agree with Richard = to make cubic as default. Since the recent improvements in cubic (below), t= he use at my side didn=92t show much problem. Perhaps making it default wil= l draw further improvement/optimization.

https://freebsdfoundation.org/wp-content/uploads/2021/05/TCP-C= ubic-is-Ready-to-Take-Flight.pdf

 

 

-- =

Cheng Cui

 

From: owner-freebsd-trans= port@freebsd.org <owner-freebsd-transport@freebsd.org> on behalf of S= cheffenegger, Richard <Richard.Scheffenegger@netapp.com>
Date: Tuesday, September 6, 2022 at 11:43 AM
To: Alexander Motin <mav@FreeBSD.org>, Gleb Smirnoff <glebi= us@FreeBSD.org>, Richard Scheffenegger <rscheff@FreeBSD.org>, Rand= all Stewart <rrs@FreeBSD.org>
Cc: <freebsd-transport@freebsd.org>
Subject: RE: Why still not Cubic?

NetApp Security WAR= NING: This is an external email. Do not click links or open attachments unl= ess you recognize the sender and know the content is safe.




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 aba= ndoned RFC draft, which only later got revived, and currently there is acti= ve 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 j= ob, 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.<= br>
Perhaps we (#transport) should discuss changing the default cc to cubic, an= d maybe revert to new_reno for stable/14 when it branches?

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 <rs= cheff@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 o= pen attachments unless you recognize the sender and know the content is saf= e.




Hi guys,

Does anybody know why after so many years FreeBSD still doesn't use Cubic C= C by default, relying on NewReno?  Does NewReno has some benefits or C= ubic still considered experimental after so many years?  In our NAS us= e cases we see that while NewReno works well in data center environments with flow control and without packet losses, C= ubic may work much better over WAN, WiFi and so on.  Are there known s= cenarios where it is worse?  Or everybody just switch to it locally?
Thanks.

--
Alexander Motin

--_000_MN2PR06MB6237B14D402EDA43329218719D7E9MN2PR06MB6237namp_--