netdev - Re: [PATCH v2 iproute2-next 1/1] tc: add dualpi2 scheduler module

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: <76bef0ad-2d27-aa2b-fe5e-02ab5c752793@kernel.org>
Date: Wed, 23 Oct 2024 22:47:00 +0300 (EEST)
From: Ilpo Järvinen <ij@...nel.org>
To: Stephen Hemminger <stephen@...workplumber.org>
cc: chia-yu.chang@...ia-bell-labs.com, netdev@...r.kernel.org, 
    dsahern@...il.com, davem@...emloft.net, jhs@...atatu.com, 
    edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, 
    dsahern@...nel.org, ncardwell@...gle.com, 
    koen.de_schepper@...ia-bell-labs.com, g.white@...leLabs.com, 
    ingemar.s.johansson@...csson.com, mirja.kuehlewind@...csson.com, 
    cheshire@...le.com, rs.ietf@....at, Jason_Livingood@...cast.com, 
    vidhi_goel@...le.com, Olga Albisser <olga@...isser.org>, 
    Oliver Tilmans <olivier.tilmans@...ia.com>, 
    Bob Briscoe <research@...briscoe.net>, Henrik Steen <henrist@...rist.net>
Subject: Re: [PATCH v2 iproute2-next 1/1] tc: add dualpi2 scheduler module

On Wed, 23 Oct 2024, Stephen Hemminger wrote:

> On Wed, 23 Oct 2024 13:04:34 +0200
> chia-yu.chang@...ia-bell-labs.com wrote:
> 
> > + * DualPI Improved with a Square (dualpi2):
> > + * - Supports congestion controls that comply with the Prague requirements
> > + *   in RFC9331 (e.g. TCP-Prague)
> > + * - Supports coupled dual-queue with PI2 as defined in RFC9332
> > + * -
> 
> It is awkward that dualPI is referencing a variant of TCP congestion
> control that is not supported by Linux. Why has Nokia not upstreamed
> TCP Prague?
>
> I would say if dualpi2 only makes sense with TCP Prague then the congestion
> control must be upstreamed first?

Hi Stephen,

In any order, there'll be similar chicken and egg problems from the 
perspective of the first comer.

The intention is to upstream Dual PI2, TCP support for AccECN (+ the L4S 
identifier support), and TCP Prague. The patches are only sent in smaller 
subsets to not overwhelm netdev and all of them are available here right 
from the start:

  https://github.com/L4STeam/linux-net-next/commits/upstream_l4steam/

...As you can see, TCP Prague is among them.

While any of those 3 main components can be used without the others due to 
how the L4S framework is architected, the practical benefits are largely 
realized when all the components are there (and enabled which is another 
big step upstreaming alone won't address anyway). So in that sense, it 
doesn't matter much which of them comes first and which last, but it 
explains why they tend to crossreference the others [*].

Implementation wise, L4S identifier support bits are required by the TCP 
Prague patch so TCP support for AccECN/L4S has to be upstreamed before TCP 
Prague. Dual PI2 does not have similar implementation dependencies to the 
other main components (AFAIK) but if you insist on including it last, I 
don't see big problem with that.

[*] There's leeway within L4S framework so that Dual PI2 or TCP Prague 
could be replaced by something else that just meets the requirements.

-- 
 i.