From: "Ilpo Järvinen" <ij@kernel.org>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: chia-yu.chang@nokia-bell-labs.com, netdev@vger.kernel.org,
dsahern@gmail.com, davem@davemloft.net, jhs@mojatatu.com,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
dsahern@kernel.org, ncardwell@google.com,
koen.de_schepper@nokia-bell-labs.com, g.white@CableLabs.com,
ingemar.s.johansson@ericsson.com, mirja.kuehlewind@ericsson.com,
cheshire@apple.com, rs.ietf@gmx.at, Jason_Livingood@comcast.com,
vidhi_goel@apple.com, Olga Albisser <olga@albisser.org>,
Oliver Tilmans <olivier.tilmans@nokia.com>,
Bob Briscoe <research@bobbriscoe.net>,
Henrik Steen <henrist@henrist.net>
Subject: Re: [PATCH v2 iproute2-next 1/1] tc: add dualpi2 scheduler module
Date: Wed, 23 Oct 2024 22:47:00 +0300 (EEST) [thread overview]
Message-ID: <76bef0ad-2d27-aa2b-fe5e-02ab5c752793@kernel.org> (raw)
In-Reply-To: <20241023085217.5ae0ea40@hermes.local>
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.
--
i.
next prev parent reply other threads:[~2024-10-23 19:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-23 11:04 [PATCH v2 iproute2-next 0/1] DualPI2 iproute2 patch chia-yu.chang
2024-10-23 11:04 ` [PATCH v2 iproute2-next 1/1] tc: add dualpi2 scheduler module chia-yu.chang
2024-10-23 15:52 ` Stephen Hemminger
2024-10-23 17:50 ` Chia-Yu Chang (Nokia)
2024-10-23 19:47 ` Ilpo Järvinen [this message]
2024-10-23 21:09 ` Stephen Hemminger
2024-10-23 15:54 ` Stephen Hemminger
2024-10-23 15:55 ` Stephen Hemminger
2024-10-23 16:01 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=76bef0ad-2d27-aa2b-fe5e-02ab5c752793@kernel.org \
--to=ij@kernel.org \
--cc=Jason_Livingood@comcast.com \
--cc=cheshire@apple.com \
--cc=chia-yu.chang@nokia-bell-labs.com \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=g.white@CableLabs.com \
--cc=henrist@henrist.net \
--cc=ingemar.s.johansson@ericsson.com \
--cc=jhs@mojatatu.com \
--cc=koen.de_schepper@nokia-bell-labs.com \
--cc=kuba@kernel.org \
--cc=mirja.kuehlewind@ericsson.com \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=olga@albisser.org \
--cc=olivier.tilmans@nokia.com \
--cc=pabeni@redhat.com \
--cc=research@bobbriscoe.net \
--cc=rs.ietf@gmx.at \
--cc=stephen@networkplumber.org \
--cc=vidhi_goel@apple.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).