From nobody Wed Oct 26 13:03:04 2022 X-Original-To: freebsd-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 4My8BG4qSvz4g44Q for ; Wed, 26 Oct 2022 13:03:18 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (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 4My8BF6rXfz472F; Wed, 26 Oct 2022 13:03:17 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from smtpclient.apple (unknown [IPv6:2003:a:e03:d412:89ab:7a74:30b8:b7f]) (Authenticated sender: macmic) by drew.franken.de (Postfix) with ESMTPSA id 871AB7D8332E7; Wed, 26 Oct 2022 15:03:15 +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 \(3731.200.110.1.12\)) Subject: Re: Too aggressive TCP ACKs From: tuexen@freebsd.org In-Reply-To: Date: Wed, 26 Oct 2022 15:03:04 +0200 Cc: Hans Petter Selasky , Zhenlei Huang , freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <701FC3D6-7AFE-46F6-977D-75CAD34646D4@freebsd.org> References: <75D35F36-7759-4168-ADBA-C2414F5B53BC@gmail.com> <712641B3-5196-40CC-9B64-04637F16F649@lurchi.franken.de> <62A0DD30-B3ED-48BE-9C01-146487599092@gmail.com> <0FED34A9-D093-442A-83B7-08C06D11F8B5@lurchi.franken.de> <330A9146-F7CC-4CAB-9003-2F90B872AC3E@gmail.com> <1ed66217-5463-fd4d-7e7a-58d9981bc44c@selasky.org> <4E92E238-798B-4293-B0D2-81E3FCB92E34@freebsd.org> To: Tom Jones X-Mailer: Apple Mail (2.3731.200.110.1.12) 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: 4My8BF6rXfz472F X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 2001:638:a02:a001:20e:cff:fe4a:feaa is neither permitted nor denied by domain of tuexen@freebsd.org) smtp.mailfrom=tuexen@freebsd.org X-Spamd-Result: default: False [-2.60 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; FROM_NO_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_CC(0.00)[selasky.org,gmail.com,freebsd.org]; ASN(0.00)[asn:680, ipnet:2001:638::/32, country:DE]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_THREE(0.00)[4]; FREEFALL_USER(0.00)[tuexen]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; TO_DN_SOME(0.00)[]; TAGGED_RCPT(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DMARC_NA(0.00)[freebsd.org]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N > On 26. Oct 2022, at 14:59, Tom Jones wrote: >=20 > On Wed, Oct 26, 2022 at 02:55:21PM +0200, tuexen@freebsd.org wrote: >>> On 26. Oct 2022, at 10:57, Tom Jones wrote: >>>=20 >>> On Sat, Oct 22, 2022 at 12:14:25PM +0200, Hans Petter Selasky wrote: >>>> Hi, >>>>=20 >>>> Some thoughts about this topic. >>>>=20 >>>> Delaying ACKs means loss of performance when using Gigabit TCP=20 >>>> connections in data centers. There it is important to ACK the data = as=20 >>>> quick as possible, to avoid running out of TCP window space. = Thinking=20 >>>> about TCP connections at 30 GBit/s and above! >>>>=20 >>>> I think the implementation should be exactly like it is. >>>>=20 >>>> There is a software LRO in FreeBSD to coalesce the ACKs before they = hit=20 >>>> the network stack, so there are no real problems there. >>>>=20 >>>=20 >>> Changing the ACK ratio seems to be okay in most cases, a paper I = wrote >>> about this was published this week: >>>=20 >>> https://onlinelibrary.wiley.com/doi/10.1002/sat.1466 >>>=20 >>> It focuses on QUIC, but congestion control dynamics don't change = with >>> the protocol. You should be able to read there, but if not I'm happy = to >>> send anyone a pdf. >> Is QUIC using an L=3D2 for ABC? >=20 > I think that is the rfc recommendation, actual deployed reality is = more > scattershot. Wouldn't that be relevant? If you get an ack for, let's say 8 packets, = you would only increment (in slow start) the cwnd by 2 packets, not 8? Best regards Michael >=20 > - Tom >=20