From nobody Fri Apr 22 18:36:42 2022 X-Original-To: net@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 04761199FFEA for ; Fri, 22 Apr 2022 18:36:50 +0000 (UTC) (envelope-from michael.tuexen@lurchi.franken.de) 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 4KlNRP01KNz3Jc4; Fri, 22 Apr 2022 18:36:48 +0000 (UTC) (envelope-from michael.tuexen@lurchi.franken.de) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:9595:a64a:4640:ba1d]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 41024721E2808; Fri, 22 Apr 2022 20:36:44 +0200 (CEST) Content-Type: text/plain; charset=us-ascii List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Subject: Re: Enabling EXTRA_TCP_STACKS on stable/13 From: Michael Tuexen In-Reply-To: Date: Fri, 22 Apr 2022 20:36:42 +0200 Cc: net@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <9EC02E05-73AA-4F31-9A52-9BC5E159D9EE@lurchi.franken.de> References: To: Gordon Bergling X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 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: 4KlNRP01KNz3Jc4 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of michael.tuexen@lurchi.franken.de has no SPF policy when checking 193.175.24.27) smtp.mailfrom=michael.tuexen@lurchi.franken.de X-Spamd-Result: default: False [-1.68 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[franken.de]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_HAM_SHORT(-0.99)[-0.987]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[net]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[193.175.24.27:from] X-ThisMailContainsUnwantedMimeParts: N > On 22. Apr 2022, at 17:55, Gordon Bergling wrote: > > Hi, > > I recently build some personal infrastructure and experimented a little > bit with tcp_bbr(4) and tcp_rack. Doing is this in a cloud environment > is a little bit priced since the kernel must be rebuild with the build > options EXTRA_TCP_STACKS defined. > > Would it be feasable to switch this option to on by default? Wouldn't we also need options TCPHTPS > > I would think that the rack and bbr are stable enough for further > adoption. I would say we can do so for RACK in the master branch. Not sure about BBR, since it implements BBRv1, which is known to be unfair in some situations (this is not a property of the FreeBSD implementation, but of the algorithm). I'm not sure about stable/13, since a lot of changes haven't been backported. We can discuss this at the next transport conference call. Are you interested to join (scheduled for May 5th, 15:00 UTC)? Best regards Michael > > --Gordon