[tsvwg] draft-white-tsvwg-nqb-02 comments

Sebastian Moeller <moeller0@gmx.de> Sat, 24 August 2019 22:07 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 34B241200C4 for <tsvwg@ietfa.amsl.com>; Sat, 24 Aug 2019 15:07:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Status: No, score=-2.349 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 6JoVkhyVJLy1 for <tsvwg@ietfa.amsl.com>; Sat, 24 Aug 2019 15:07:11 -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 6F19212008F for <tsvwg@ietf.org>; Sat, 24 Aug 2019 15:07:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1566684426; bh=5oNg+8FZBTgWcDBcwfORDs1kVbu7dScZhnGXohTjoSM=; h=X-UI-Sender-Class:From:Subject:Date:To; b=BG/rxaIOoytVvAX2vqr3cwhlj0cIqSucBtXlo6JgKL4xy78NC+3h8+dkM/M/HL6nk XUG3PdgHSwbo8vHCJeyjVskmzc3NXUBzVTvLv3wsXnyKXQXQFQQcKnMJfgNzA2obdt Q6thvlh4wcq5Jlc5ri7YCZ2H2+fpeBxzvpgBtY2g=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([]) by mail.gmx.com (mrgmx105 []) with ESMTPSA (Nemesis) id 1MTiPl-1heJNs3TXJ-00U3oe; Sun, 25 Aug 2019 00:07:05 +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: <2169599D-5993-48DB-B598-0B1AC50FF977@gmx.de>
Date: Sun, 25 Aug 2019 00:07:04 +0200
To: tsvwg IETF list <tsvwg@ietf.org>, Dave Taht <dave@taht.net>, ECN-Sane <ecn-sane@lists.bufferbloat.net>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:JeMidLctClWKLHYA1UlXUD78SU/DwqGAXL5fOaWm04/WRbq7gth lIWfxrFEOmscdoc3kECmZ1i5pO27fSTdxOOiloClKS/+UZVUyd+T5VrVHjJixPnijPYAfjE +5Y79FZ3GyV+oTxQtZgIbHun1hx0AQ5PNyMzO/N/1C539QULrmEXlNjThFpa7MCscw0cqWq 6m9x2QCaMnCdCUrpnXJxw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:f1nvOwE3DQY=:WH2ojHXLYFK0hL0igYy9GV JO+4DDPdGrF8sMFu4Dgm117tC8d05MdsMbHvAb4hDobUdeKCk4HcjZUVHwFL7A5ph2PWfPTSU ez3Qgi8oot8o+AXe0TAgHSVwFC7teObjbWzgbn2xuLvdWzLSD8jmus2DDkLaiMjFfFEd0I/B2 j+69WoF0c2VEl2wFszP0CyCmWishWgb8R3Q4J1T7DDlkKtCKYNUVgu1bIkd15INANlal1KEVE texGLVtM3GPIJ8vYCNAfRPyi/txMt0UjHAysGSpwaVtDacERGjYEOIS+zhbGVZ2OBNOy/wYj4 FNu8K5i6KiJVFDc1+IgqedoMxiLvemvFHSOMY321fGmhJp3xUFzPQFnal8At9Kfz7ol61yrlp O7fymduAT1wjmOljf6e1NHM3x7cok+vsMAMhT+JnozLqu9/gAy651occTdXaSWxMCn4pAz8wQ 0nLRn8+w1HJVJrhV6eGpmXQ7HE1eV4H7fwDmy8/cYH8Lq1F50wtpPlE//pbZCKXGDA3BbCQ4t uQN22Ob9rbgwj0WFFal3VQsupvytYvV+6MdRbJ4ifuoKpntKDJmHj1yML00eaLjr3tRtpVYW2 tkXuRP7Srgo1EHrq5Pk91n9dmAvQRlwLd3yl1pTGsrES6oDfXLihfN7a1e94Vq64jTRHSJEDq AhjAJPFqUgwTXGHeZuoXHrOxj6LcBTxdMPJicZOHjsU0/vuYLTMp23uJ47RPaNGmNvVcV2jX7 Ei5hjqUToZb3+8R1MOLMhE8bC3q0QwpywdrcUAaShbTJRNDbKPaGcOhSyouvdBbfO163+YOB9 TNen3b+q/NRUAFfIAhJ2ow1i1f3bQE3JBUqj5/lKDf5Rag1eS7gFh0FgEiL2AkH/IlpP4do4A N1uuKm3n0UD3gcg2NRRCZ+MRSpus6WV0+hqFYBCOOlrNDyXFe6RXD/mbR6RQkuBjApJ0C76es Xi1a0IFTeTIPOUTvUrMAS3MtoXJqb/o7kVdEHZHfDaVBnOlSB81ARote2ZDereij909tDir+M alfrsQVNDSxmegWnIbOPf29pJoRzLrIMc6J9zweCFVMOg8o5E4J8LbkGrwQQQ9P2Im/R/C6dg Ghtjauna7iOPLjn6X7Pi+HZoKJL4cbQdwf85Oqyspwvw+lHbr87PHWOJSmdnXpt48SIs1p5Np 1M/oc=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/fRRyysSO5AY20DW8F7RxyDmQP3k>
Subject: [tsvwg] draft-white-tsvwg-nqb-02 comments
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: Sat, 24 Aug 2019 22:07:14 -0000

Dear tsvwg,

	[SM] I had a look at draft-white-tsvwg-nqb-02 and amongst other things I tripped over the following section

"8.3. WiFi Networks

WiFi networking equipment compliant with 802.11e generally supports either four or eight transmit queues and four sets of associated CSMA parameters that are used to enable differentiated media access characteristics. Implementations typically utilize the IP DSCP field to select a transmit queue.

As discussed in [RFC8325], most implementations use a default DSCP to User Priority mapping that utilizes the most significant three bits of the DiffServ Field to select User Priority. In the case of the 0x2A codepoint, this would map to UP_5 which is in the "Video" Access Category (one level above "Best Effort").

Systems that utilize [RFC8325], SHOULD map the 0x2A codepoint to UP_6 in the "Voice" Access Category."

	[SM] This is highly debatable! See RFC8325 for a description of the consequences of selecting AC_VO, in short AC_VO entails a considerable advantage of acquiring airtime (over all other ACs) that will immediately affect ALL users of the same channel (and nearby channels); that is all networks using that channel in the RF-neighbourhood, in addition AC-VO also seems to grant longer TXOP (airtime slots) than both AC_BK and AC_BE.
	Using AC_VO for any data flow that is not both reasonably low bandwidth and latency sensitive is rather rude and should not be enshrined in an IETF draft. As NBQ seems specifically designed to also allow for high bandwidth flows, AC_VO should be off-limits, as the consequences will not be restricted to the wifi network carrying the NQB flows. If a big data flow is abusing AC_VO it will effectively slow all other AC's traffic to a trickle and since wifi (currently) is mostly half-duplex it will also affect traffic in both directions.
	Let me try to phrase my objection in IETF conforming terms, this recommendation needs to be reconciled with the mapping recommendations in https://tools.ietf.org/html/rfc8325 for different types of traffic. I realize that this draft references RFC8325, but it clearly fails to understand the rationale for dividing different traffic types into different access classes due to the side-effects these classes have.

Best Regards