netdev - Re: Potential impact of commit dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win

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]

Message-ID: <89d0b3d3-7c32-4138-8388-eab11369245f@quicinc.com>
Date: Mon, 20 May 2024 11:09:05 -0600
From: "Subash Abhinov Kasiviswanathan (KS)" <quic_subashab@...cinc.com>
To: Eric Dumazet <edumazet@...gle.com>
CC: <soheil@...gle.com>, <ncardwell@...gle.com>, <yyd@...gle.com>,
        <ycheng@...gle.com>, <quic_stranche@...cinc.com>,
        <davem@...emloft.net>, <kuba@...nel.org>, <netdev@...r.kernel.org>
Subject: Re: Potential impact of commit dfa2f0483360 ("tcp: get rid of
 sysctl_tcp_adv_win_scale")

On 5/20/2024 9:12 AM, Eric Dumazet wrote:
> On Sun, May 19, 2024 at 4:14 AM Subash Abhinov Kasiviswanathan (KS)
> <quic_subashab@...cinc.com> wrote:
>>>>>>>>>>> We recently noticed that a device running a 6.6.17 kernel (A)
>>>>>>>>>>> was having
>>>>>>>>>>> a slower single stream download speed compared to a device running
>>>>>>>>>>> 6.1.57 kernel (B). The test here is over mobile radio with
>>>>>>>>>>> iperf3 with
>>>>>>>>>>> window size 4M from a third party server.
>>>>>>>>>>
>>>>>>>>
>>>>> This is not fixable easily, because tp->window_clamp has been
>>>>> historically abused.
>>>>>
>>>>> TCP_WINDOW_CLAMP socket option should have used a separate tcp socket
>>>>> field
>>>>> to remember tp->window_clamp has been set (fixed) to a user value.
>>>>>
>>>>> Make sure you have this followup patch, dealing with applications
>>>>> still needing to make TCP slow.
>>>>>
>>>>> commit 697a6c8cec03c2299f850fa50322641a8bf6b915
>>>>> Author: Hechao Li <hli@...flix.com>
>>>>> Date:   Tue Apr 9 09:43:55 2024 -0700
>>>>>
>>>>>       tcp: increase the default TCP scaling ratio
>>> With 4M SO_RCVBUF, the receiver window scaled to ~4M. Download speed
>>> increased significantly but didn't match the download speed of B with 4M
>>> SO_RCVBUF. Per commit description, the commit matches the behavior as if
>>> tcp_adv_win_scale was set to 1.
>>>
>>> Download speed of B is higher than A for 4M SO_RCVBUF as receiver window
>>> of B grew to ~6M. This is because B had tcp_adv_win_scale set to 2.
>> Would the following to change to re-enable the use of sysctl
>> tcp_adv_win_scale to set the initial scaling ratio be acceptable.
>> Default value of tcp_adv_win_scale is 1 which corresponds to the
>> existing 50% ratio.
>>
>> I verified with this patch on A that setting SO_RCVBUF 4M in iperf3 with
>> tcp_adv_win_scale = 1 (default) scales receiver window to ~4M while
>> tcp_adv_win_scale = 2 scales receiver window to ~6M (which matches the
>> behavior from B).
> 
> What problem are you trying to solve that commit  697a6c8cec03c229
> did not ?
> 
Commit 697a6c8cec03c229 added support to increase initial scaling ratio 
to 50% to match behavior of configurations which were using SO_RCVBUF 
and only tcp_adv_win_scale = 1 (prior to commit dfa2f0483360).

My proposed change is adding support for configurations which are using 
SO_RCVBUF and other tcp_adv_win_scale values. In my case, device B was 
using SO_RCVBUF and tcp_adv_win_scale = 2.