From nobody Thu Nov 10 09:28:54 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 4N7GkC2txBz4XH5n for ; Thu, 10 Nov 2022 09:29:07 +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 4N7Gk65dH7z3h1p for ; Thu, 10 Nov 2022 09:29:02 +0000 (UTC) (envelope-from tuexen@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=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; dmarc=none Received: from smtpclient.apple (unknown [212.140.138.205]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 3A9F77089E94C; Thu, 10 Nov 2022 10:28:55 +0100 (CET) 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: <7EDD65B7-5FCD-42E1-A9E8-AA5139B0A81E@gmail.com> Date: Thu, 10 Nov 2022 09:28:54 +0000 Cc: Hans Petter Selasky , freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6FE15D58-D19F-4B7F-8548-40B9573A7F7F@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> <5A501643-1E81-4A8C-8DDC-094371DC03D7@gmail.com> <7EDD65B7-5FCD-42E1-A9E8-AA5139B0A81E@gmail.com> To: Zhenlei Huang 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-Spamd-Bar: -- X-Spamd-Result: default: False [-2.70 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[193.175.24.27:from]; FROM_NO_DN(0.00)[]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE]; RCVD_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_THREE(0.00)[3]; 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]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4N7Gk65dH7z3h1p X-ThisMailContainsUnwantedMimeParts: N > On 10. Nov 2022, at 08:07, Zhenlei Huang wrote: >=20 >> On Nov 9, 2022, at 11:18 AM, Zhenlei Huang = wrote: >>=20 >>=20 >>> On Oct 22, 2022, at 6:14 PM, Hans Petter Selasky = wrote: >>>=20 >>> Hi, >>>=20 >>> Some thoughts about this topic. >>=20 >> Sorry for late response. >>=20 >>>=20 >>> Delaying ACKs means loss of performance when using Gigabit TCP = connections in data centers. There it is important to ACK the data as = quick as possible, to avoid running out of TCP window space. Thinking = about TCP connections at 30 GBit/s and above! >>=20 >> In data centers, the bandwidth is much more and the latency is = extremely low (compared to WAN), sub-milliseconds . >> The TCP window space is bandwidth multiply RTT. For a 30 GBit/s = network it is about 750KiB . I think that is trivial for a >> datacenter server. >>=20 >> 4.2.3.2 in RFC 1122 states: >> > in a stream of full-sized segments there SHOULD be an ACK for at = least every second segment=20 >> Even if the ACK every tenth segment, the impact of delayed ACKs on = TCP window is not significant ( at most >> ten segments not ACKed in TCP send window ). >>=20 >> Anyway, for datacenter usage the bandwidth is symmetric and the = reverse path ( TX path of receiver ) is sufficient. >> Servers can even ACK every segment (no delaying ACK). >>=20 >>>=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 the network stack, so there are no real problems there. >>=20 >> I'm OK with the current implementation. >>=20 >> I think upper layers (or application) have (business) information to = indicate whether delaying ACKs should be employed. >> After googling I found there's a draft [1]. >>=20 >> [1] Sender Control of Delayed Acknowledgments in TCP: = https://www.ietf.org/archive/id/draft-gomez-tcpm-delack-suppr-reqs-01.xml >=20 >=20 > Found the html / pdf / txt version of the draft RFC. > https://datatracker.ietf.org/doc/draft-gomez-tcpm-ack-pull/ Can you specify the problem you are facing or trying to solve? Best regards Michael >=20 >>=20 >>>=20 >>> --HPS >>>=20 >>>=20 >>=20 >> Best regards, >> Zhenlei >=20 >=20