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

Message-ID: <20241023140946.2f6f66ce@hermes.local>
Date: Wed, 23 Oct 2024 14:09:46 -0700
From: Stephen Hemminger <stephen@...workplumber.org>
To: Ilpo Järvinen <ij@...nel.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 22:47:00 +0300 (EEST)
Ilpo Järvinen <ij@...nel.org> wrote:

> 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.
> 

Understood, just want to make sure that we don't end up with some component
accepted and another necessary and related piece gets rejected by kernel community.