Date: Thu, 10 Nov 2022 09:28:54 +0000 From: tuexen@freebsd.org To: Zhenlei Huang <zlei.huang@gmail.com> Cc: Hans Petter Selasky <hps@selasky.org>, freebsd-net@freebsd.org Subject: Re: Too aggressive TCP ACKs Message-ID: <6FE15D58-D19F-4B7F-8548-40B9573A7F7F@freebsd.org> In-Reply-To: <7EDD65B7-5FCD-42E1-A9E8-AA5139B0A81E@gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 10. Nov 2022, at 08:07, Zhenlei Huang <zlei.huang@gmail.com> wrote: >=20 >> On Nov 9, 2022, at 11:18 AM, Zhenlei Huang <zlei.huang@gmail.com> = wrote: >>=20 >>=20 >>> On Oct 22, 2022, at 6:14 PM, Hans Petter Selasky <hps@selasky.org> = 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6FE15D58-D19F-4B7F-8548-40B9573A7F7F>