[tsvwg] NQB versus WIFI access classes Gedankenexperiment

Sebastian Moeller <moeller0@gmx.de> Mon, 09 September 2019 09:45 UTC

Return-Path: <moeller0@gmx.de>
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 D623212021D for <tsvwg@ietfa.amsl.com>; Mon, 9 Sep 2019 02:45:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ixexaEoVgZKR for <tsvwg@ietfa.amsl.com>; Mon, 9 Sep 2019 02:45:31 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13E46120120 for <tsvwg@ietf.org>; Mon, 9 Sep 2019 02:45:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568022328; bh=i4XQ6PVPpWyYQhI2oH9uTtLEPqpZrt9fGrrBj7KKd68=; h=X-UI-Sender-Class:From:Subject:Date:To; b=Zlr/XeKuGGRZJcIoj+dStq9V+fkGMXUSySnpGLtPBzfMQ3+GI7Sf5TbDAeQwGme+s 0rtPhCxOWJny/MNeRo1NHOkduBmjL+xwgPz5fwpoQf2QbIljqyRH0fRKie0SAw+R0k YSexLVb3+PmDWkLHNRLpUXhtOAIyaWDXc3nIzzek=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by mail.gmx.com (mrgmx003 []) with ESMTPSA (Nemesis) id 0LoEPJ-1iee2b1U0f-00gDxa for <tsvwg@ietf.org>; Mon, 09 Sep 2019 11:45:28 +0200
From: Sebastian Moeller <moeller0@gmx.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <1320709E-9A21-4BAB-A8F0-A4393F372727@gmx.de>
Date: Mon, 9 Sep 2019 11:45:27 +0200
To: tsvwg IETF list <tsvwg@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:TaW8h9D5dF1A5pZpSgpLQdVO/zC+oRBIYdn00Maq8n07ROsZRmg 84Q7PVpGonQRNI7vxJvBs3k+jmOWUht4rQ37PqnNg7JIZTW2x6IfbOwgX7lcdyhFqTWhC8M 3WL3hXxm9FVqT1gFg5AVxJadDvT5SaQ6jojtFME2HbicpDmgEXxl3EWV7D3K82CL2Egx8P9 nUBoMkFdyv10KIQyIr3Zw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:0iClbD6hy8I=:5KDsk8CoCh0Sl2HTAYipur LKVf2gbp6J6tR/SBIgywxqtS1DMpsq3hRyQ+j7eu5wI9QhISbgASqaOKz8EQLm5Ww0NfUhwhw ajhR59uOLwwuZgWIOj6z8NXXvAvwHYCVWZxckBOsKOYf3xmNn8i6BPbgmaasmR+tytBW+1kil 3gYE8Ir/M5rp1Jgn9hit05+140o5dTV4QbQJKlCTH0f5Ju8wP2JG5D3NUEOS0FsgK2SzA/LQk CS3SKTZ6Jaha5PjylZTExCOhUSCRZ23jOpCWBmqdGSSOfa1/preYuieZAjikJmfkHOy8kDgxa jPfyAIGQzd2lLU3iqMDc1oE2J737ZSWX89FweDJ6K7hAbGfYG80VtGvgED4CTQorV4OJRQj9v I5toKfocudy4nlxstnjbo0QRzqCeoaNaLOyC9CmiGfotoxdDCL3CNtPombid3PyqA+a1xWnb9 SXGjoqeS+XJOcbYRvWCueQWKR6p6Ug75UfRLtIgutMXDFM29vdYXpUNePaqyM483H0AxnUFZl Pe17WlGiCDgSq4SlgDGwDXcnjz1mn6UsSwv2bgX2DSBmM62M919Vs/sRE4tqzpinM9m8XqS1N KT13KqxP0HCQ/fSH4nrke4EZVx7lzvcesrngnTJ2mClGeg1fx3a3M+C4Qi7davN39EiZFter3 mujiFSpj71HtY2tTFQYoIsCFF7uVHyKhAv/byCuYHf+qGV5m7p9elryThQLTZpX3BzrqNFohQ SrvXkdRTTvg9XOV6UaZ2/SUbde9oIuXxfaKvceOQZcuq1KYNtya/gsJVm6E3ksgkSwQDN+O5z XsD3E9yqYNgcAj4uy4yai4z+DU7k2gzDviMd+s+wc1MEKKhROSlyiDFGLS/BYjXIaa5Dw6gbf VSWXb8q0gOBtzHlRKLQ42cGFdyPE/c9nMI2sbwvjcHnQTKhWH1LkK1Z//9ayAEqXUCUsnyagU /pp1BE77r4QW8eDDgZryJkn8vNxQmBwgaF3zfMy9WCSxxgw/ivMv2SKxMaMXyzZIxMSFDHjid JXlQL3dIzJomx4YES6O6mKD4SPZbq+FE8r1etYTQjdvGoauRmLzjtB7l117+0kAlay6w6oWtL A144h5IvbIDJI5FJUL1b6GmxQmLttmSqZ8fxUqjVPJXce+/cDwWhsi1RPbFruwvb6mY558sEZ TTgHRGWj4kT2E1Q/McpgxniiXR15Ez9V68DHCQeMGFZphm0gMt647vMza0Y2xJW3U08MS8Lh+ ViCcD9811CWnTSEsv
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/J0GXEV0ypO6rjap7QYqTBz_m9D0>
Subject: [tsvwg] NQB versus WIFI access classes Gedankenexperiment
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 09 Sep 2019 09:45:33 -0000

Dear List,

since it seems clear to me that my objections against using AC_VI or AC_VO for indifferently for NQB marked packets, mainly falls on deaf ears.

Let me introduce a small Gedankenexperiment to demonstrate why this a patently problematic idea especially in the light of the stated goals of the NQB marking and L4S in general.

Let me propose the following scenario (sticking somewhat to Bob's numbers):

An dualQ type AQM on the ISP side of the access link which tries to split (a gross-rate of) 120 Mbps between a QB and a NQB queue more or less equally*. So full saturation steady state will be:
60 Mbps QB traffic
60 Mbps NQB traffic

Now let's look exactly at that saturating-load situation that is surprisingly common on end-user internet access links (otherwise an NQB mark would not really be needed)

The exact number of flows does not matter for my argument, but just to make things simple assume each flow takes of 10 Mbps of the gross-rate. So we have 
6 * NQB flows @10Mbps each (say paced video streams), dscp marked 0x2A
6 * QB flows @10Mbps average (say non-paced bulk data flows), dscp "marked" 0x00

On the end user side this data is flowing over wifi links from the CPE to the actual endpoints.

As long as wifi  rates stay >> 120 Mbps, things will just work out as intended by NQB more or less independent of which AC is assigned to NQB traffic.

But now the neighbors come home and there is going to be channel contention in the RF-medium and achievable data rates for our example household drop to 60 Mbps.

What the NQB /L4S approach seems to intend in that situation would be a grace-full  reduction in rates for both NQB and QB flows ot an aggregate of ~30 Mbps each.

But with NQB mapping to AC_VI/AC_VO what is going to happen ist, that the NQB flows will secure almost all of the tx-ops and hence starve out the QB-flows almost completely (doubly so, since the NQB airtime hogging will make it hard for QB data to reach the endpoints but also equally hard for ACKs from there to go back to the senders). The upstream dualQ AQM will see more or less NQB~60Mbps, QB~0Mbps, and will not help at al, since 60/0 is a valid traffic split.
I might be wrong, but that inevitable outcome does not seem to be well aligned with the stated goals of the NQB code point.

I present this as a Gedankenexperiment, but it is not hard to turn this into an actual experiment...

And that is the core rationale why I believe that NQB should stay at AC_BE; in addition to the observations that the current loose requirements for a flow to be NQB need to be aligned with rfc8325 so that the NQB aggregate only gets the lowest AC of any of its valid member traffic classifications according to rfc8325.

Best Regards

*) I am not fully certainwhat kind of guarantees L4S actually makes for the bandwidth split between QB and NQB/L4S flows, but for this discussion I assume it aims for rough equality.