[tsvwg] draft-ietf-tsvwg-nqb-23 inconsistency of advice

Sebastian Moeller <moeller0@gmx.de> Wed, 29 May 2024 06:53 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 5BCC8C15199D for <tsvwg@ietfa.amsl.com>; Tue, 28 May 2024 23:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.844
X-Spam-Status: No, score=-6.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmx.de
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CeesKr60MEW3 for <tsvwg@ietfa.amsl.com>; Tue, 28 May 2024 23:53:41 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4154C1516F3 for <tsvwg@ietf.org>; Tue, 28 May 2024 23:53:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1716965614; x=1717570414; i=moeller0@gmx.de; bh=vnR62ERRAm0P0A+oMvEgRAdUYlYd630pdimyPoS4u1w=; h=X-UI-Sender-Class:From:Content-Type:Content-Transfer-Encoding: Mime-Version:Subject:Message-Id:Date:To:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=fEcVW+AjMuQyKwHO2OL5ibd+ERoltOWrU8a17Z38c9bMsMmmWqPHzbcMMD8CP0+G +PwVcP+bGGYVgnWvTwIkwmFK4CsL6RICluHdHySLQ3e2uQGRYEOqfsMg4ObQ8zFx4 aulg7wT5UcBIDYXdn9y7Ylq3+4juwUQe5gJhz5gmGsMJ4oKkALPza39QCiqScJQQg cETF33RVbmFcY3g6pCGc+aSOvg73XUL2HRmH3k4U/tuq4bJhl136ne5DTEr3ZRuRP w+XVzSLsb3Xohn+HcMK8qIB6yoazQDWMUVITvjeASZ1VOOqNuIOXccyWTahdxi/mL yIVu2vkcbdWnGgqGmw==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from smtpclient.apple ([]) by mail.gmx.net (mrgmx104 []) with ESMTPSA (Nemesis) id 1MOA3F-1rsbyO3BkX-00ND6o for <tsvwg@ietf.org>; Wed, 29 May 2024 08:53:34 +0200
From: Sebastian Moeller <moeller0@gmx.de>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
Message-Id: <B01B60E2-4A3B-4DED-A83E-74D8334666BC@gmx.de>
Date: Wed, 29 May 2024 08:53:22 +0200
To: tsvwg <tsvwg@ietf.org>
X-Mailer: Apple Mail (2.3774.600.62)
X-Provags-ID: V03:K1:tEDJPwRoqPbPwx3D4Tz6ZWRPQu54y7d6yTjk8PKVXtyWn+LPFjM iaaRdK7VIUp3n542CUUeuXcMDLol6LDXp0NCPAJA/UarMnEsRVSOBXGi+OWARzzHhb089Z8 uDT0xXYRJ2TW2fMdz9+QH5amZLXHM992nS+QYj4ri25phLYkqd8Bu8R7aw0fuNocbc096/b 45EnsrKeClkkTxTcPu0/Q==
UI-OutboundReport: notjunk:1;M01:P0:LmdSTOuXiLE=;km40ic5eGvU0HsBxCSS0N6ExgFx LYECEP8syTBEpx9EprKihdb3S3RDqrdnwtQYPtNvxJEisGx2VVbxbVQ70Mb+PDu0+q0e7E0VD jXbeP8CyMU/96xFyiXR94gSTvvji/XDhgqSyn6t1yZitYMdMaoeZOZ3MJBXxUWhfyvfdZLxSD 8RZrY5qSkn1YVriQqLywhpFnj3lLK9P125zAEnJEqy3aanm0Yys8KkN7xyoSsisTYqotFP1Zj rGOBg/uVXMFeXExFYXabtDbE89hAw8s6p5MVgcCV6QrwspjesBbgj+lQHbWBrP/KlazIIBG3g hKYF66rlTDGx+0LGfGWfvpuGciDumMq84+cxGzc2vfMaJrncMZqAtunn7IGZIQuW5IirknWHo Ep+Yk80tDTYnMR6nEkQGwo7JtgnSBan1xqCEQWlj6e/syw/PSsIjKL77pdPY5eTquZFOBknEE OKfWf7h4GAFBe8WvRaNU4Ilf1gBeFayWXC+ZFMZL3QT9l2Aij3MKIB34Nk+O27fucSeIfVfcU ujfJOmibJts3yPUJkSQT3wGykliYa39VC3jeTZ5UzM4+NtjA7KLrOsGyfJlD9xT/ehPy6f1iD 11AtRIcpcSjFRBrSQQayoYNyNrlkgn49Lb18TqsPG9KdsOIU0c2F+1FC7NvA8qkjPOPb4LWRb wFhnxwtVrt6pGB/qmwRETS91S+mNl3F5g2bUuO9UYnsXefBlrPK21P/sKyc6UcBkRziJ7EBDP G73nbrBTys6iKo+rfsg/y0+fmOaNHQl+HfXs+LyFWzriYODQKWWKEemRhdKeRkIIkNWSh7A04 2UhpI9cxfMXW2lLl2EkRN02UfwU+D/udVniBGErSMKjCs=
X-MailFrom: moeller0@gmx.de
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
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [tsvwg] draft-ietf-tsvwg-nqb-23 inconsistency of advice
List-Id: Transport Area Working Group <tsvwg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/07n7lcDlG67UHxCIrX5I-K-uV8g>
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>

Dear list,

draft-ietf-tsvwg-nqb-23 contains IMHO incongruent advice:

Alternatively, operators of networks with lower rate links MAY choose to disable NQB support (and thus aggregate traffic marked with the NQB DSCP with Default traffic) on these lower rate links. For links that have a data rate that is less than ten percent of "typical" path rates, it is RECOMMENDED that the NQB PHB be disabled and for traffic marked with the NQB DSCP to thus be carried using the Default PHB. However, the NQB DSCP SHOULD NOT be re-marked to the Default DSCP (0).

So the advice is to follow general IETF recommendation for unhandled DSCPs and keep the DSCP value but treat them as default forwarding.

While https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-23#name-interoperability-with-exist contains:
    • For application traffic that originates outside of the Wi-Fi network, and thus is transmitted by the Access Point, the choice of DSCP 45 does create a potential for abuse by non-compliant applications. But, opportunities exist in the network components upstream of the Wi-Fi Access Point to police the usage of the NQB DSCP and potentially re-mark traffic that is considered non-compliant, as is recommended in Section 4.4.1. Furthermore, it is a common practice for residential ISPs to re-mark the Diffserv field to zero on all traffic destined to their customers' networks, and any change to this practice done to enable the NQB DSCP to pass through could be done alongside the implementation of the recommendations in Section 4.4.1.

But here we relay on actual DSCP remapping to 0  as a safety mechanism... even though a few section above we explicitly advised against doing that.
So if that is supposed the be a back-stop for WiFi, then we need to change the "6.1. Guidance for Lower-Rate Links" section to reference to the corner case of legacy WiFi.

In addition I would like to see the claim "it is a common practice for residential ISPs" substantiated quantitatively. The last two ISPs (both big European Telcos) I was /am customer of do not generally remark DSCPs to zero (I took packet captures of my link and looked at the DSCPs of incoming packets, if the claim would be true all packets would be DSCP 0, but that is not what I observed and e.g. ).
If we consider that remarking to zero is against IETF recommendations and at best done inconsistently, we should remove this argument from "7.3.1. Interoperability with Existing Wi-Fi Networks".


P.S.: The solution to all of this is still rather obvious, instead of making the side effect of NQB on WiFi opt-out, change the desired special treatment of NQB over WiFi to be opt-in with the default behaviour to stick to AC_BE: et voila instant safety by design and no having to rely on circumstantial safety via expected DSCP re-mapping behaviour of non participating parties.