From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1B8CD3CB35 for ; Sat, 24 Aug 2019 18:07:07 -0400 (EDT) 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 ([77.12.241.96]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MTiPl-1heJNs3TXJ-00U3oe; Sun, 25 Aug 2019 00:07:05 +0200 From: Sebastian Moeller 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 , Dave Taht , ECN-Sane 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-Spam-Flag: NO 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= Subject: [Ecn-sane] draft-white-tsvwg-nqb-02 comments X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2019 22:07:08 -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 Sebastian=