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

[Stephen Hemminger <stephen@networkplumber.org>]

On Wed, 23 Oct 2024 22:47:00 +0300 (EEST)
Ilpo Järvinen <ij@kernel.org> wrote:

> On Wed, 23 Oct 2024, Stephen Hemminger wrote:
> 
> > On Wed, 23 Oct 2024 13:04:34 +0200
> > chia-yu.chang@nokia-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.