netdev - Re: [PATCH] Add a sysctl to allow TCP window shrinking in order to honor memory limits

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] [thread-next>] [day] [month] [year] [list]

Date: Tue, 6 Jun 2023 10:17:28 -0500
From: Mike Freemon <mfreemon@...udflare.com>
To: Jason Xing <kerneljasonxing@...il.com>,
 Stephen Hemminger <stephen@...workplumber.org>,
 Eric Dumazet <edumazet@...gle.com>, Neal Cardwell <ncardwell@...gle.com>
Cc: netdev@...r.kernel.org, kernel-team@...udflare.com
Subject: Re: [PATCH] Add a sysctl to allow TCP window shrinking in order to
 honor memory limits


On 6/5/23 21:09, Jason Xing wrote:
> On Tue, Jun 6, 2023 at 6:44 AM Stephen Hemminger
> <stephen@...workplumber.org> wrote:
>>
>> On Mon, 5 Jun 2023 15:42:29 -0700
>> Stephen Hemminger <stephen@...workplumber.org> wrote:
>>
>>>> sysctl: net.ipv4.tcp_shrink_window
>>>>
>>>> This sysctl changes how the TCP window is calculated.
>>>>
>>>> If sysctl tcp_shrink_window is zero (the default value), then the
>>>> window is never shrunk.
>>>>
>>>> If sysctl tcp_shrink_window is non-zero, then the memory limit
>>>> set by autotuning is honored.  This requires that the TCP window
>>>> be shrunk ("retracted") as described in RFC 1122.
>>>>
>>>> [1] https://www.rfc-editor.org/rfc/rfc7323#appendix-F
>>>> [2] https://www.rfc-editor.org/rfc/rfc7323#section-2.4
>>>> [3] https://www.rfc-editor.org/rfc/rfc1122#page-91
>>>> [4] https://www.rfc-editor.org/rfc/rfc793
>>>> [5] https://www.rfc-editor.org/rfc/rfc1323
>>>>
>>>> Signed-off-by: Mike Freemon <mfreemon@...udflare.com>
>>>
>>> Does Linux TCP really need another tuning parameter?
>>> Will tests get run with both feature on and off?
>>> What default will distributions ship with?
>>>
>>> Sounds like unbounded receive window growth is always a bad
>>> idea and a latent bug.
>>
>> FYI - I worked in an environment where every bug fix had to have
>> a tuning parameter to turn it off. It was a bad idea, driven by
>> management problems with updating. The number of knobs lead
>> to confusion and geometric growth in possible code paths.
>>
> 
> I agree. More than this, shrinking window prohibited in those classic
> RFCs could cause unexpected/unwanted behaviour.

I discuss the RFCs in more detail in my blog post here:
https://blog.cloudflare.com/unbounded-memory-usage-by-tcp-for-receive-buffers-and-how-we-fixed-it/