[tsvwg] draft-ietf-tsvwg-nqb, more questions

Sebastian Moeller <moeller0@gmx.de> Mon, 04 November 2019 22:24 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 370AF120B97 for <tsvwg@ietfa.amsl.com>; Mon, 4 Nov 2019 14:24:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.348
X-Spam-Status: No, score=-2.348 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, URIBL_BLOCKED=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 hBCY5P82bnwi for <tsvwg@ietfa.amsl.com>; Mon, 4 Nov 2019 14:24:53 -0800 (PST)
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 2182C120B74 for <tsvwg@ietf.org>; Mon, 4 Nov 2019 14:24:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1572906283; bh=gyVdnXK9TbOHYo91CRdFlfHQ6ewDLQBKqgpWz7VRvXo=; h=X-UI-Sender-Class:From:Subject:Date:To; b=SHGfDo3u0ejs+tx4cUGxOdxtN/Jwov4rNwtQPIWysbzCnUt6pUXVs7QoODMLLndgk SvqYP/XxynvkPeM1yC0EgRM8aSWTFhOJvVuBQz3Sp4WPF/3jssLL9s1jYV5fTLo6AA jk9kPL18aAiYqJjziB2VQCXlr4O+AFpDzVedgB2s=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([]) by mail.gmx.com (mrgmx105 []) with ESMTPSA (Nemesis) id 1MXGvG-1iRGLm0qqM-00Yjo6 for <tsvwg@ietf.org>; Mon, 04 Nov 2019 23:12:00 +0100
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: <90ED003C-CC25-4ED4-90D8-BA572E39D852@gmx.de>
Date: Mon, 4 Nov 2019 23:11:58 +0100
To: tsvwg IETF list <tsvwg@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:qD5lnPqwcrEZdiGR63obRFI/1MkKo145qJB4tMbHyPUXzm65L6X ys2PoQPb2tf46bi0/pz3U3Utqr0waICjADGGqhOnNkpWoysbgyZurHjP/LV/GPsO9tzvOzz PtC3Mq6MRsgFp5Cs9fryWSR3Aecm+uDZgDZmQJJSDwPCOdHraO/bRl7XF/WjW0vmO3oYsVW bARRPFRl7gjxxz/Fq7D5w==
X-UI-Out-Filterresults: notjunk:1;V03:K0:gJM5MKmFdjI=:jjVgReFeYzixHwFPe3A+D0 26MR+vAVGC24pRVclFVeWdVQzASb/WCdgUm3TBcPInEjf9Kmm38e/zqwLRf9ZYMEF4UJLJ4bp vY4G91BrEUMnaocWzdiYee1vEbOSao5qXdmzD8+FUwHG+wFtbrveE5mwfuCjQ4d6kjdnJm3DS TdOEiul+eod/s7okj1DYrDwHAk1/vYXhqWWbSUYflVaTsCpMRjKNbnYHTufksIzHtY9FDrCMr TStgzKiNLU5qHpHusDex/S6mRXIYMOY0uTVDSQMquBgyguIiAuuGWtkFwg6JT/Op9E+rluhdu jtn3ovxJT80oHtb+IGqUgi2Gq8YZdlFiwNfL/Y+d47tt9EPr5NoL6qH+4iG8Qw0EEVQo2TpnJ qtbZrVpmGK2wKt9s+ycTKrlSwiWEH2keo6OZdoo1GpPPTl3AGvOyS25x8XDomkO+bTirca5Sh KcTOTjGPri0zg4BVRICzEtGCtMdaaiMK5+VSsnpuQHaKwq4nPtNbAWoErgBzQpFwSpuk+SbLh wNzoPKYcwpFPVCZHpv+I4c64Gr/3nk3VDZaJis3v29656r5RWO3oLDCAqho/MgWDem+4A09fo Ama+TPNAS+BxlEfDKNYq6OfurIWxAUaFdc8ZRcJMe2cPd0P3jntyrW6m6m7qXXkNjYoDNNK/6 hHCmlo3bNu1JH7j4WNN6pHqhNn4mzfZm2d0t0DRz7tNxEHxvF71QYiRlDx5UIZ0xZIr7j1aI9 CdQCAIl5o3OtdmoKE3w5pECD5Z2WGKnYD0hPIjImigH5lNcLwSWP3ostiVpc9mPlH0ZS7h+7C k6uPFknAZsqp7mH0IhVMEVsvEiiJYhgdkdDPKXlIyzuBxVd2rmaUC1iyYtXfbAADX+8CGdimR xdp02trfggs10CE4gUiYN6hlxoprCVYIM89UPVc22UaBFyFBMdlNF3tcTuDkaXdK7qIldDGNk oIqkIIRgDiYaGNMqIL6sV3J7gSTSTGLe5BzekI8ALPkXv0cCV8dpDqz6Qoj1jD6cJ7TBrrb4X 89bWiXIYC7U3TEUZG+cRP8UrsxYfhOOIBoTp+bmeC56wzt0uLR1YFlZOyGrvlEbCr6PZGVBUb x+EoqZS0OpeAUThxHwg6YY+vbA2WIJE75xyPfjFSwqHoFvZOE5bppaaDXwZRW6C/oASd291oD w3nj1VcUaIZXoXmSQmuuWGb1g6giu0ILm7A7tpUpUfQNX6y/N1juiX+Rjs+ZUdu5I61mHhD/a PAZFGquBoZ/yYQh1BfjxqoasN6ITBryLqCPLdOPKoye/nLVNuBCHlpN7bxME=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ujTZWnBqHrR5du-dyyf9owdVQwg>
Subject: [tsvwg] draft-ietf-tsvwg-nqb, more questions
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, 04 Nov 2019 22:24:59 -0000

Regarding https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/?include_text=1

7.3.  WiFi Networks

   WiFi networking equipment compliant with 802.11e generally supports
   either four or eight transmit queues and four sets of associated EDCA
   parameters (corresponding to the four WiFi Multimedia Access
   Categories) that are used to enable differentiated media access
   characteristics.  Implementations typically utilize the IP DSCP field
   to select a transmit queue, but should be considered as Non-
   Differentiated Services-Compliant Nodes as described in Section 4 of
   [RFC2475].  As a result this document discusses interoperability with
   WiFi networks, as opposed to PHB compliance.

   As discussed in [RFC8325], most existing implementations use a
   default DSCP to User Priority mapping that utilizes the most
   significant three bits of the DiffServ Field to select "User
   Priority" which is then mapped to the four WMM Access Categories.  In
   order to increase the likelihood that NQB traffic is provided a
   separate queue from QB traffic in existing WiFi equipment, the 0x2A
   codepoint is preferred for NQB.  This would map NQB to UP_5 which is
   in the "Video" Access Category.

   Systems that utilize [RFC8325], SHOULD map the NQB codepoint to UP_5
   in the "Video" Access Category.

   In order to preserve the incentives principle, WiFi systems SHOULD
   configure the EDCA parameters for the Video Access Category to match
   those of the Best Effort Access Category.

[SM] This last section is puzzling: if the wifi system configures AC_VI with EDCA parameters that match the AC_BE parameters, AC_VI ceases to be different from AC_BE, in that case picking a codepoint that automatically maps to CS0 and hence to AC_BE  seems much safer, simpler and straight forward to me. 
Especially since essentially none of the millions deployed WiFi APs out there will a) have this configured like proposed already and b) none of the consumer APs I know actually allow to easily adjust EDCA parameters at all. I guess I must be missing something and would be delighted to be shown why the proposed text is the right thing.
My take on this still is, if NQB traffic is sufficiently sparse using AC_VI can be justified, but without any rate limits this has the potential of being quite unfair to concurrent APs on the same channel (as well as the neighboring channels that overlap with the selected). 
I do not want to sound alarmist, but given the number of cable-ISP WiFi-APs (as indicated by a SSID containing the ISPs name) in my city, I believe making sure that those APs will not basically start hogging most airtime seems the prudent thing to do. If there are sufficient backstops in place (like rate limiting or automatic down-marking if the traffic is not sparse enough) to avoid the described situation, I am all for it.

The text probably should also openly discuss that in WiFi/WMM the four available queues by design have different priorities, and by moving NQB out of the default AC_BE while leaving QB flows in there, this effectively runs against  the following text in the draft: "The NQB queue SHOULD be given equal priority compared to queue-building traffic of equivalent importance." (leaving alone the question how an AP or a station is supposed to measure importance)