IETF Logo Mail Archive

[tsvwg] Why L4S need a separate queue?

Vasilenko Eduard <vasilenko.eduard@huawei.com> Tue, 16 April 2024 14:06 UTC

Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46792C14F5F6 for <tsvwg@ietfa.amsl.com>; Tue, 16 Apr 2024 07:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjzdrxVnohaM for <tsvwg@ietfa.amsl.com>; Tue, 16 Apr 2024 07:06:13 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF0CFC14F5F4 for <tsvwg@ietf.org>; Tue, 16 Apr 2024 07:06:12 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VJm4F5kbbz6H7kh for <tsvwg@ietf.org>; Tue, 16 Apr 2024 22:04:13 +0800 (CST)
Received: from mscpeml100004.china.huawei.com (unknown [7.188.51.133]) by mail.maildlp.com (Postfix) with ESMTPS id C0DBA140B3C for <tsvwg@ietf.org>; Tue, 16 Apr 2024 22:06:10 +0800 (CST)
Received: from mscpeml500004.china.huawei.com (7.188.26.250) by mscpeml100004.china.huawei.com (7.188.51.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Tue, 16 Apr 2024 17:06:10 +0300
Received: from mscpeml500004.china.huawei.com ([7.188.26.250]) by mscpeml500004.china.huawei.com ([7.188.26.250]) with mapi id 15.02.1258.028; Tue, 16 Apr 2024 17:06:10 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: Why L4S need a separate queue?
Thread-Index: AdqQBF1OOK2tycKzRSuYODOPjNF7oA==
Date: Tue, 16 Apr 2024 14:06:10 +0000
Message-ID: <6284927dbd704a6abdec7fca7f6bade2@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.199.56.41]
Content-Type: multipart/alternative; boundary="_000_6284927dbd704a6abdec7fca7f6bade2huaweicom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/wCSYD4ER6X1NZeTos7tCMOVfhTI>
Subject: [tsvwg] Why L4S need a separate queue?
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2024 14:06:19 -0000

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

v2.23.0 | Report a Bug | By Email