Re: [tsvwg] Why L4S need a separate queue?

Vasilenko Eduard <vasilenko.eduard@huawei.com> Thu, 18 April 2024 07:58 UTC

From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: Why L4S need a separate queue?
Thread-Index: AdqQBF1OOK2tycKzRSuYODOPjNF7oABXlGZA
Date: Thu, 18 Apr 2024 07:58:12 +0000
Message-ID: <8a83c60e2dd841679f4a0b1848830b6f@huawei.com>
References: <6284927dbd704a6abdec7fca7f6bade2@huawei.com>
In-Reply-To: <6284927dbd704a6abdec7fca7f6bade2@huawei.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_8a83c60e2dd841679f4a0b1848830b6fhuaweicom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/F3JQNaCJ-yexA_QXKEEq65YwsdU>
Subject: Re: [tsvwg] Why L4S need a separate queue?
Precedence: list

If somebody in the future would develop yet another CC algorithm (nobody could predict future requirements),
But dependency between algorithms (formula) is hard-coded in the router's hardware,
Then it is an infrastructure replacement again.
It was wrong to put a formula for CC cooperation/fairness into hardware.

It may have a small positive effect on the transition period to isolate new traffic from legacy,
But BBR has surpassed half of the traffic already and resolved this problem differently.

Especially in the situation when the formula was analytically derived from the wrong assumptions.
It is a time of errata for RFC 9332 where RENO and CUBIC dependencies are claimed on the square root of marking probability.

By the way, RFC 9332 references PI2 publication which claims different formulas for RENO and CUBIC. CUBIC is cubical as anybody could guess - very different from RENO.
CUBIC has almost replaced RENO on the market, but RFC 9330 and RFC 9332 propose to use a formula from RENO. It is not logical at all.
Even if nobody spotted that analytical formulas are wrong, why the formula from RENO was chosen for DualQ, not for CUBIC?
It is an additional errata for the RFC 9332.

Opensource has won IETF again and unfortunately, I suspect why. This silence is a good sign of what is going on in TSVWG.
Nobody wants to discuss the problem in essence. Everything has already been decided by politics.
Eduard
From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Vasilenko Eduard
Sent: Tuesday, April 16, 2024 17:06
To: tsvwg@ietf.org
Subject: [tsvwg] Why L4S need a separate queue?

Hi Experts,
For sure, some balancing is needed between the new CCA against the old CCA to achieve the fairness. It may have a complex formula - no problem with that.
But why this formula has been put on routers?
BBR (without ECN feedback) has finally developed a good enough formula to play nicely with CUBIC.
I have not seen a test for BBR with ECN against CUBIC with ECN or against CUBIC without ECN. If anybody saw it - please share.
No doubt that such a formula could be developed for BBR with ECN (if it is not a part of BBR already).
Any CCA MUST have fairness with CUBIC in one queue - the world has a huge number of already installed hardware (with fixed schedulers).

Then the only thing that would be needed from routers is to support ECN instead (or in addition) of drop.
And ECN(1) would not be needed.

I do not see a value in the requirement for an additional scheduler type on routers.
It would not affect the performance. Because any new CCA MUST have fairness for one queue anyway for adoption strategy.
It just additionally complicated L4S adoption (with rip&replace approach).

PS: everything above is my personal opinion.

Best Regards
Eduard Vasilenko
Senior Architect
Network Algorithm Laboratory
Tel: +7(985) 910-1105

[tsvwg] Why L4S need a separate queue? Vasilenko Eduard
Re: [tsvwg] Why L4S need a separate queue? Vasilenko Eduard
Re: [tsvwg] Why L4S need a separate queue? Sebastian Moeller
Re: [tsvwg] Why L4S need a separate queue? Gorry Fairhurst