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]

Date: Fri, 17 May 2024 01:08:53 -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/16/2024 12:49 PM, Subash Abhinov Kasiviswanathan (KS) wrote:
> On 5/16/2024 2:31 AM, Eric Dumazet wrote:
>> On Thu, May 16, 2024 at 9:57 AM Eric Dumazet <edumazet@...gle.com> wrote:
>>>
>>> On Thu, May 16, 2024 at 9:16 AM Subash Abhinov Kasiviswanathan (KS)
>>> <quic_subashab@...cinc.com> wrote:
>>>>
>>>> On 5/15/2024 11:36 PM, Eric Dumazet wrote:
>>>>> On Thu, May 16, 2024 at 4:32 AM Subash Abhinov Kasiviswanathan (KS)
>>>>> <quic_subashab@...cinc.com> wrote:
>>>>>>
>>>>>> On 5/15/2024 1:10 AM, Eric Dumazet wrote:
>>>>>>> On Wed, May 15, 2024 at 6:47 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
>>> What happens if you let autotuning enabled ?
> I'll try this test and also the test with 4M SO_RCVBUF on the device 
> configuration where the download issue was observed and report back with 
> the findings.
With autotuning, the receiver window scaled to ~9M. The download speed 
matched whatever I got with setting SO_RCVBUF 16M on A earlier (which 
aligns with previous observation as the window scaled to ~8M without the 
commit).

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.