Re: [PATCH 5/6] tcp: Don't try to transmit right after the peer shrank the window to zero

[Stefano Brivio <sbrivio@redhat.com>]

On Mon, 18 Aug 2025 12:56:09 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Fri, Aug 15, 2025 at 06:10:41PM +0200, Stefano Brivio wrote:
> > If the peer shrinks the window to zero, we'll skip storing the new
> > window, as a convenient way to cause window probes (which exceed any
> > zero-sized window, strictly speaking) if we don't get window updates
> > in a while.  
> 
> Strictly speaking, not storing the new zero window feels slightly
> wrong to me - I wonder if it would be more correct to store the zero
> window, but still send window probes as a special case.

Yeah, it's wrong but it's not really obvious what value we should use
at that point. With a recent kernel version, there would be no problem
storing 0, waiting for a window update which will come soon after, and
reserve the special case I already added (1 as window size) for
zero-window probes, triggered via timer.

But without 8c670bdfa58e ("tcp: correct handling of extreme memory
squeeze"), and with e2142825c120 ("net: tcp: send zero-window ACK when
no memory"), the window update never comes, so we would need to wait
for the timer to expire before we send an explicit zero-window probe,
which takes a while (two seconds).

With this trick, instead, we keep the latest advertised value, which
is actually the latest correct value, and retry sending what we were
originally sending as soon as we have more data from the socket, which
would becomes available quite soon in all the practical cases where the
kernel shrinks the window to zero.

Maybe we could store zero, and use WINDOW_DEFAULT (14600 bytes) on
socket activity. The RFC simply says we need to send zero-window
probes at some point, not that we should assume a broken receiver,
but unfortunately between e2142825c120 and 8c670bdfa58e it's like that.

-- 
Stefano