[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241023085217.5ae0ea40@hermes.local>
Date: Wed, 23 Oct 2024 08:52:17 -0700
From: Stephen Hemminger <stephen@...workplumber.org>
To: chia-yu.chang@...ia-bell-labs.com
Cc: 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, ij@...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 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?
Powered by blists - more mailing lists