netdev - Re: [PATCH bpf-next 0/7] bpf: Propagate cn to TCP

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

Date:   Tue, 26 Mar 2019 11:07:19 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Eric Dumazet <eric.dumazet@...il.com>
Cc:     brakmo <brakmo@...com>, netdev <netdev@...r.kernel.org>,
        Martin Lau <kafai@...com>, Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH bpf-next 0/7] bpf: Propagate cn to TCP



On 03/26/2019 10:01 AM, Alexei Starovoitov wrote:

> The next tcp congestion control algorithm should be implementable in bpf.

Congestion control do not need per-packet decision, and can indeed be
implemented in bpf.

Some researchers even have implemented them in user space (CCP if I remember well)

> If kernel was extensible to that degree likely there would have been
> no need to bypass it and invent quic.

QUIC is a complete re-design, and works around fundamental things
that TCP can not change.

bpf in TCP could not have changed the rise of QUIC or any other
modern transport, really.

Lets stop this discussion, we are digressing :)