Message-ID: <CAL+tcoB=4-dCWaEZL7HqLM+2j__iW+LrZANd+RAL4PkxE+kkCw@mail.gmail.com>
Date: Mon, 10 Mar 2025 06:17:28 +0100
From: Jason Xing <kerneljasonxing@...il.com>
To: Andrew Easton <Andrew@...ton24.com>
Cc: "David S. Miller" <davem@...emloft.net>, "David S. Ahern" <dsahern@...nel.org>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Simon Horman <horms@...nel.org>, 
	"Linux Kernel Mailing List, Network Subsystem" <netdev@...r.kernel.org>, 
	"Linux Kernel Mailing List, Sysctl API ABI" <linux-api@...r.kernel.org>
Subject: Re: Add sysctl for tcp_delayed_ack

Hi Andrew,

On Mon, Mar 10, 2025 at 2:33 AM Andrew Easton <Andrew@...ton24.com> wrote:
>
> Subject: Add sysctl for tcp_delayed_ack
>
> Hi everyone,
>
> this is a proposed patch for adding a sysctl for
> disabling TCP delayed ACK (IETF RFC 1122)  without
> having to patch software to constantly poke sockets
> with TCP_QUICKACK which apparently resets on
> subsequent operations, see tcp(7).
>
> For my personal computer networks experimenting with
> globally disabling TCP delayed ACK across two other
> operating systems seems to have considerably improved
> congestion control.  (While I propose only anecdotal
> evidence, there is more to it.  Am open to the
> ensuing technical discussion, but only if that turns
> out to be a good use of other people's time.)
>
> This is my first proposed kernel patch and it is

Thanks for proposing this patch :)

As to the idea itself, my personal feelings are:
1) It might be suitable for local kernels instead of public kernels,
even though we internally have a similar patch a few years ago
already.
2) The reason why I hesitated to submit a patch like this before is it
may change/override the default socket behavior which may bring
unexpected impacts. It's a global knob...
3) To be frank, the delayed ack mechanism prevails for so many years
and truly solves too many pure ack packets on the wire issue. And I
believe only a minority of clients try to turn it off.
4) Recently, I was thinking of implementing a delayed ack max timeout
(which you can refer to tcp_delack_max() and see how it works). As I
mentioned, I also hesitate to do so.

Of course, no matter what my thoughts are, it finally depends on the
TCP maintainer's call :)

Thanks,
Jason

> likely missing a whole bunch of details.  For
> example:
>
> 1. Where is the TCP ACK delay computed for IPv6?
> Could not identify this in file net/ipv6/tcp_ipv6.c .
>
> 2. Perhaps, adding kernel configuration options for
> the ncurses interface is desireable.  What is a good
> example to learn from?
>
> 3. Perhaps, setting constants in file
> include/uapi/linux/sysctl.h may be unnecessary, but I
> have not found any guidelines on when these CTL
> numbers are necessary.  Likely, because I did not
> read the documentation carefully enough.  Any
> pointers are appreciated.
>
> 4. The default should probably be a value like
> net.ipv4.tcp_delayed_ack=1 that preserves the current
> behavior and hence is backwards compatible for user
> space.  A value of net.ipv4.tcp_delayed_ack=0 should
> globally (for IPv4) disable TCP delayed ACK.  Would
> also like to add the option for IPv6, but see point
> (1).
>
>
> In case a similar sysctl has already been proposed
> and rejected in the past, please point me to the
> mailing list archives, if that is not too
> inconvenient.
>
>
> Which questions have I failed to ask that I should
> have asked?
>
> Errors and lack of research are on me.
>
> Thank you for sharing your time.
>
> Andrew
>
>
>
>
>

Powered by blists - more mailing lists