On Mon, 18 Aug 2025 12:56:09 +1000
David Gibson
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