netdev - 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <7ec9b05b-7587-4182-b011-625bde9cef92@quicinc.com>
Date: Tue, 14 May 2024 22:46:51 -0600
From: "Subash Abhinov Kasiviswanathan (KS)" <quic_subashab@...cinc.com>
To: <edumazet@...gle.com>, <soheil@...gle.com>, <ncardwell@...gle.com>,
        <yyd@...gle.com>, <ycheng@...gle.com>
CC: <quic_stranche@...cinc.com>, <davem@...emloft.net>, <kuba@...nel.org>,
        <netdev@...r.kernel.org>
Subject: Potential impact of commit dfa2f0483360 ("tcp: get rid of
 sysctl_tcp_adv_win_scale")

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.

The radio conditions are the same between the devices so that maximum 
achievable download speed will be the same. Both devices have the same 
tcp_rmem values.

We captured tcpdump at the device and the main difference was that the 
receiver window advertised in the ACKs was going upto a maximum of ~2M 
in A vs ~6M in B. By explicitly increasing the window size in iperf3 in 
A, the download speed of A was able to match that of B which suggests 
that the RTT was high and needed a larger window size to achieve the 
download speed. We do not have tcp_shrink_window enabled.

We noticed that there were some changes to window size done in commit 
dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win_scale"). After 
reverting this commit in A, we observed that the receiver window 
advertised in ACKs matches B.

We logged free_space, allowed_space and full_space in 
__tcp_select_window() in both devices and observed that the 
allowed_space was 6MB+ on both devices, however the full_space was 
smaller in A as the tp->window_clamp was smaller. The free_space was 
smaller in A compared to B which I believe is an expected consequence of 
the commit.

Could you please advise on how we need to handle this. We are open to 
trying out any debug patches.