netdev - Re: [PATCH net v4 2/3] tcp_cubic: fix to match Reno additive increment

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

Message-ID: <adb76a64-18de-41b4-a12d-e6bc3e288252@gmail.com>
Date: Mon, 19 Aug 2024 16:03:20 -0500
From: Mingrui Zhang <mrzhang97@...il.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: davem@...emloft.net, ncardwell@...gle.com, netdev@...r.kernel.org,
 Lisong Xu <xu@....edu>
Subject: Re: [PATCH net v4 2/3] tcp_cubic: fix to match Reno additive
 increment

On 8/19/24 03:22, Eric Dumazet wrote:
> On Sat, Aug 17, 2024 at 6:35 PM Mingrui Zhang <mrzhang97@...il.com> wrote:
>> The original code follows RFC 8312 (obsoleted CUBIC RFC).
>>
>> The patched code follows RFC 9438 (new CUBIC RFC):
> Please give the precise location in the RFC (4.3 Reno-Friendly Region)

Thank you, Eric,
I will write it more clearly in the next version patch to submit.

>
>> "Once _W_est_ has grown to reach the _cwnd_ at the time of most
>> recently setting _ssthresh_ -- that is, _W_est_ >= _cwnd_prior_ --
>> the sender SHOULD set α__cubic_ to 1 to ensure that it can achieve
>> the same congestion window increment rate as Reno, which uses AIMD
>> (1,0.5)."
>>
>> Add new field 'cwnd_prior' in bictcp to hold cwnd before a loss event
>>
>> Fixes: 89b3d9aaf467 ("[TCP] cubic: precompute constants")
> RFC 9438 is brand new, I think we should not backport this patch to
> stable linux versions.
>
> This would target net-next, unless there is clear evidence that it is
> absolutely safe.

I agree with you that this patch would target net-next.

> Note the existence of tools/testing/selftests/bpf/progs/bpf_cc_cubic.c
> and tools/testing/selftests/bpf/progs/bpf_cubic.c
>
> If this patch was a fix, I presume we would need to fix these files ?
In my understanding, the bpf_cubic.c and bpf_cc_cubic.c are not designed to create a fully equivalent version of tcp_cubic, but more focus on BPF logic testing usage.
For example, the up-to-date bpf_cubic does not involve the changes in commit 9957b38b5e7a ("tcp_cubic: make hystart_ack_delay() aware of BIG TCP")

Maybe we would ask BPF maintainers whether to fix these BPF files?