[tsvwg] Re: Request to review diffserv spec: draft-ietf-tsvwg-nqb

Vasilenko Eduard <vasilenko.eduard@huawei.com> Tue, 28 May 2024 05:20 UTC

Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6C37BC151707 for <tsvwg@ietfa.amsl.com>; Mon, 27 May 2024 22:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id i0FHWBNwryUs for <tsvwg@ietfa.amsl.com>; Mon, 27 May 2024 22:19:58 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D078C151524 for <tsvwg@ietf.org>; Mon, 27 May 2024 22:19:58 -0700 (PDT)
Received: from mail.maildlp.com (unknown []) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VpLMN01z8z6JB6f; Tue, 28 May 2024 13:16:00 +0800 (CST)
Received: from mscpeml100004.china.huawei.com (unknown []) by mail.maildlp.com (Postfix) with ESMTPS id 4BBD11400C9; Tue, 28 May 2024 13:19:55 +0800 (CST)
Received: from mscpeml500004.china.huawei.com ( by mscpeml100004.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.34; Tue, 28 May 2024 08:19:54 +0300
Received: from mscpeml500004.china.huawei.com ([]) by mscpeml500004.china.huawei.com ([]) with mapi id 15.02.1258.034; Tue, 28 May 2024 08:19:54 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] Re: Request to review diffserv spec: draft-ietf-tsvwg-nqb
Thread-Index: AQHar+EfKDc1XIaQDUyzNIOihzGkZbGqlj8ggAAX0ACAADN9UIABOnnQ
Date: Tue, 28 May 2024 05:19:54 +0000
Message-ID: <950432d946054b8da5af4c4b37caa5b7@huawei.com>
References: <171619088820.9700.17122047615729502291@ietfa.amsl.com> <65a001f0-386e-4d3a-b41a-1ae75a195aca@erg.abdn.ac.uk> <075c9da4-df83-4286-85f3-d36553fac3ba@gmail.com> <aa71804ee5194509914e74e717766247@huawei.com> <HrBN5VBqLPXzuh9BCMrR8cWB1fKo5aGo3Axw3nT9XQDftHqNXdtWFvnUBt0N8N3YbC_Mj77KPzk_UbGvlPbq3pcIdC1m4tBg2kmf9BPk6uM=@ealdwulf.org.uk> <20e06b97714b412681a2d444525c928b@huawei.com>
In-Reply-To: <20e06b97714b412681a2d444525c928b@huawei.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MailFrom: vasilenko.eduard@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tsvwg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Brian E Carpenter <brian.e.carpenter@gmail.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "Black, David" <David.Black@dell.com>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [tsvwg] Re: Request to review diffserv spec: draft-ietf-tsvwg-nqb
List-Id: Transport Area Working Group <tsvwg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/jtwxCDktFBZDJirRT7gJ2-UbFe0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Owner: <mailto:tsvwg-owner@ietf.org>
List-Post: <mailto:tsvwg@ietf.org>
List-Subscribe: <mailto:tsvwg-join@ietf.org>
List-Unsubscribe: <mailto:tsvwg-leave@ietf.org>

Hi all,
I would like to state it again:
NQB currently creates an impression that this security issue is solvable later.
My point: it is not! Only by full replacement of NQB by flow-based AQM (like FQ-Codel).

But the primary purpose of my message is to state that Sebastian Moeller almost persuaded me off-line that it is a critical issue for subscribers too.
Games DoS each other, NQB would help them to DoS much more effectively (20x less traffic).
I am just a little hesitant to accept that gaming is something important.
-----Original Message-----
From: Vasilenko Eduard 
Sent: Monday, May 27, 2024 13:41
To: 'Alex Burr' <alex.burr@ealdwulf.org.uk>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>; tsvwg@ietf.org; Gorry Fairhurst <gorry@erg.abdn.ac.uk>; Black, David <David.Black@dell.com>
Subject: RE: [tsvwg] Re: Request to review diffserv spec: draft-ietf-tsvwg-nqb

Academia has a *huge* number of research with the keywords "elephant" and "mice". Just google if interested. To get to the point immediately add "monitoring" to the search.
They mostly have small tables for loosely aggregated "elephants" and heavily aggregated 'mice' with the mechanism to promote between tables (sometimes very advanced, Bloom filter or even more complex).
In all cases it is something small (like 10^4 flows overall on the link) and for a small proportion of "elephants" (single digit X%).
Anyway, even after this it consumes considerable resources, the implementation is shown for P4 best case or Xeon typically.
Flow-based solutions could be optimized, but it has limits. I am pessimistic about having it scalable even for 100GE links.

What is good for "monitoring" is not good for AQM.

Of course, it is possible to read draft-briscoe-docsis-q-protection. Just I doubt that after so many academic papers it is possible to break through this problem.
-----Original Message-----
From: Alex Burr <alex.burr@ealdwulf.org.uk> 
Sent: Monday, May 27, 2024 13:24
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>; tsvwg@ietf.org; Gorry Fairhurst <gorry@erg.abdn.ac.uk>; Black, David <David.Black@dell.com>
Subject: Re: [tsvwg] Re: Request to review diffserv spec: draft-ietf-tsvwg-nqb

Hi Vasilenko, tsvwg

See [AB] inline

On Monday, 27 May 2024 at 07:26, Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org> wrote:

> Hi all,
> Brian has attracted my attention to the draft.
> I believe that the document has a small contradiction to itself:
> It is rightly stated that per-flow AQM is not scalable, the separate queue is proposed instead.
> At the same time, the protection proposed against malicious actors is proposed per-flow (I could not propose a better one too).
> Hence, we could implement something per-flow (like FQ-Codel) in the first place - we do not need this mechanism, it looks redundant.

[AB] the draft refers to an example mechanism, draft-briscoe-docsis-q-protection. 
I'm not an author of either draft, and I don't want to claim anything on their behalf. But one thing that's of interest is that that mechanism, if I've understood it correctly, scales not in the number of flows overall but with the number of non-compliant flows. It seems plausible that only a small, fixed number of resources for non-compliant flows would provide a sufficient incentive for many scenarios.
Eg, if a developer classifies their flows as NQB without reading the docs properly, and finds that their application is punished, they are most likely to revert the classification.
I'm not sure that draft-briscoe-docsis-q-protection recommends a sufficient punishment, but that can be discussed. There is also some discussion of its behavior under DoS.