netdev - Re: Question about TCP delayed-ack and PUSH flag behavior

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAL+tcoD_DxWPFUiQaB8va=pw+g_Aku_4bhO+d7x9Cfgz6fHKig@mail.gmail.com>
Date: Sat, 15 Feb 2025 08:16:08 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: 제임스 <jaymaacton@...il.com>
Cc: Willy Tarreau <w@....eu>, netdev@...r.kernel.org
Subject: Re: Question about TCP delayed-ack and PUSH flag behavior

On Sat, Feb 15, 2025 at 2:00 AM 제임스 <jaymaacton@...il.com> wrote:
>
> 2025년 2월 14일 (금) 오후 12:12, Willy Tarreau <w@....eu>님이 작성:
> >
> > On Fri, Feb 14, 2025 at 12:03:17PM -0500, ??? wrote:
> > > Hi netdev,
> > >
> > > When tcp stack receives a segment with PUSH flag set, does the stack
> > > immediately send out for the corresponding ACK with ignoring delay-ack
> > > timer?
> > > Or regardless of the PUSH flag, delay-ack is always enforced?
> >
> > It depends, it's possible for the application to force a delayed ack
> > by setting TCP_QUICKACK to zero. This is convenient for web servers
> > that know they respond quickly and can merge this ack with the
> > response to save one packet.
>
> Thanks but my question is about the kernel's default behavior.
> It sounds like there is no interaction between PUSH and delayed-ack,
> and it should be handled by application scope.
> Can someone confirm my understanding?

I think there are two patches that may arouse your interests:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4720852ed9afb1c5ab84e96135cb5b73d5afde6f
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1ef9696c909060ccdae3ade245ca88692b49285b

As you may conclude from the above link, no direct interaction between
PSH flag and delayed-ack, but we do handle the !ping-pong case. I
guess that  you may compare the implementation with RFC 9293[1] and
find the difference?

[1]: https://datatracker.ietf.org/doc/html/rfc9293#section-3.9.1.3

Thanks,
Jason