Date: Wed, 26 Oct 2022 09:57:11 +0100 From: Tom Jones <thj@freebsd.org> To: Hans Petter Selasky <hps@selasky.org> Cc: Zhenlei Huang <zlei.huang@gmail.com>, Michael Tuexen <michael.tuexen@lurchi.franken.de>, freebsd-net@freebsd.org Subject: Re: Too aggressive TCP ACKs Message-ID: <Y1j2ZzHaFt/YA5Et@spacemonster> In-Reply-To: <1ed66217-5463-fd4d-7e7a-58d9981bc44c@selasky.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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 22, 2022 at 12:14:25PM +0200, Hans Petter Selasky wrote: > Hi, > > Some thoughts about this topic. > > 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! > > I think the implementation should be exactly like it is. > > There is a software LRO in FreeBSD to coalesce the ACKs before they hit > the network stack, so there are no real problems there. > Changing the ACK ratio seems to be okay in most cases, a paper I wrote about this was published this week: https://onlinelibrary.wiley.com/doi/10.1002/sat.1466 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. - Tom
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Y1j2ZzHaFt/YA5Et>