[tsvwg] Re: NQB claim of DSCP-
Sebastian Moeller <moeller0@gmx.de> Fri, 31 May 2024 07:09 UTC
Return-Path: <moeller0@gmx.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D54C1840DC; Fri, 31 May 2024 00:09:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.844
X-Spam-Level:
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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oezTWa5SH6i0; Fri, 31 May 2024 00:09:23 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 9DE02C15108B; Fri, 31 May 2024 00:09:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1717139360; x=1717744160; i=moeller0@gmx.de; bh=pgqNb728s8S3X/eCeW3KUzftXsvqXRjLhBKyjbpghuU=; h=X-UI-Sender-Class:Content-Type:Mime-Version:Subject:From: In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id: References:To:cc:content-transfer-encoding:content-type:date:from: message-id:mime-version:reply-to:subject:to; b=sOBJJIBAATL1yosKF39FdsH9BzqXA1vs1Hn5zVYW0bkmbsuFwRGk+B20jiLRTWe6 hkZibnUyORtOhY3iW5+a6a5KJKfg+0egGtnU1n9mH7iDiUt2vtk30N2TsSazmBLI1 HG3UNhZdYXLWwfaIfBlXo/ivaGMhQZMFrEZ31xVqXeNC3ey9QA5PNm26/wIofDV6K 0Htf0JMzqkOD6XTdAmVDuXC42kJ5jPxTjU3wLwkatxWLLOJEMGisdo3Hp1f8cslbS SQY8HTjo9U40S3aJSWv9TPvlYjqFH3d/6Fjx/G59LJn6BR/WfBOo/WmmZOmtqSMhU bzSl+K3q+1pA6gFTCg==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MZTqg-1s1GUQ2zZO-00WZ9z; Fri, 31 May 2024 09:09:20 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <1B85F167-AC2F-4024-BCC9-C0CA565DCED6@comcast.com>
Date: Fri, 31 May 2024 09:09:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <AA79DF37-0E82-4111-84C0-3F4612223402@gmx.de>
References: <B9CF3DCA-03E5-497C-9951-6D24DFDCCE72@gmx.de> <1B85F167-AC2F-4024-BCC9-C0CA565DCED6@comcast.com>
To: "Livingood, Jason" <jason_livingood=40comcast.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3774.600.62)
X-Provags-ID: V03:K1:6k9WzBMhXDuOVcqOZzEl8p/yPRTk1SEJUdBhK9wX3GIRYTF/dak oC+jVhk0F8l8QHG+aM8d80XdnmsGHRvCMGzbsJKjZQJoybnUax/6pzS97QxU9NWzCFLryPS kCtL+cBgFe6mTqUXYme6WaNoSTYMxeq6FP/WBCAI2DRlp1K7yNPIH9RcmF5/B9WI9anLD8C hiZVW28lNbNGUijZaiEPA==
UI-OutboundReport: notjunk:1;M01:P0:7NgZIrWrb3g=;JVc31GV3W2BmlfA+aCGHYPAgkNC Rjez0n9fdEmvnFTAaEx03RAvpxu+VZIGo6FQWI+rmNd7IPlfix48JQS2kJ5VkSAQyQNsSjCm6 jOUinCKibh9GCL2fpLDnZFhr4wRnbPVDwGsBNcW3chT2mGOgimS2Om6O7H/psGA4N5ARbTpaO CoFPzDrL5DUGu01AvNbkSMoTg6Hw95qrFjE8X6CNpOf0akJZ8urFLBqvMQphHz/3rUpCVtLH0 QNSSLzeZUpBd3QH0/1AygyjyqY4DAjZUfDRJ6lEPN0FvZEgSrn0XOOf7cKSVq2KqaPUxN1SmJ cOhfS41Q6UqkDfwg/W498UCGJ4hXH8YwqxZ/cltLyywgs1afPEjmDlj913dHRTexSDiByAOal SNSK6XZUV5tqcG/1CLtrb/t4zgaVNyghd1TP0Un5yEGM6JncVeq/e6JmzPkirbDS0FbiDlmfo wUDSls5J4VLOIbPELpMKPZuH820DS1KVIjB0ZbSgM0Cnl6stZc6gex/rKjCbAj0FmR0kkY53y YfXWU1OSlrMszKAvJ3qRUGdyxkhp4L3btkCUOq7MoDEzNbthgf36NC2uA4T0yVRtoD0AoMg43 G9O9zFPq3p7jiyogF1KI03iNG2i51meMsGdnXTB1VPkR4s5rYRcK83wczVmRcA2UoNeupziPi 2ePJGmORc6xs7T82E+1cBfSXKJXjtZiVPPhgv5MwTi4I+cLsiGoEC/Ab/mSKaMAq0Kxka5+3H 0cr3fDB7GuncqrmIEx0NIbtWY1VbU3uXfqOzbvaADPOALUVoeT86F4qPzPWwVbDmBt5X0MQUf WLGl+TpNpTG/dtMVzS7a9mjL/l9VbISWvAgUi5DzwyreY=
Message-ID-Hash: FNP2BNF2OIX5G3EUDTFBIJVYNCSR5G27
X-Message-ID-Hash: FNP2BNF2OIX5G3EUDTFBIJVYNCSR5G27
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
CC: tsvwg <tsvwg@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [tsvwg] Re: NQB claim of DSCP-
List-Id: Transport Area Working Group <tsvwg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/qAKzbwnXGsO-AbmywchODoA4N5o>
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>
Hi Jason, > On 30. May 2024, at 15:43, Livingood, Jason <jason_livingood=40comcast.com@dmarc.ietf.org> wrote: > > On 5/30/24, 03:49, "Sebastian Moeller" <moeller0=40gmx.de@dmarc.ietf.org <mailto:40gmx.de@dmarc.ietf.org>> wrote: > >> We can easily see that my ISP (O2/Telefonica) does not remark DSCP decimal 45 (they do remap tos 192 (CS6) and tos 224 (CS7) but I assume that these DSCPs are used in the O2 network itself; > > [JL] I wonder if that is unintentional - it would be great to pull in a Telefonica network engineer to see. [SM] Good question, curious to hear some answer to that one. What makes you believe that this might not be intended? Are the industry agreements in place that recommend that? Yet, I actually think that Telefonica does the right thing here, it will remark those DSCPs right at its AS boundary that it uses itself like CS6 and CS7 (apparently by bleaching the highest three bits) and it will leave DSCPs it does not use intact, exactly what I seem to remember several IETF documents imply as the intended course of action (both the re-marking of CS6/7 and the leaving other DSCPs intact). A (cursory) look over rfc4594, rfc7657, rfc9435, rfc8100 seems to support the view that the IETF encourages DSCP traversal end to end but recommends to sanitise CS6/7. So I can not say whether O2's behaviour here is intentional or unintentional, but it seems to be aligned with our recommendations. >> This makes me wonder whether the hypothesis should be removed from the draft or sufficiently quantified. I am open to the possibility that most other ISPs will remark DSCPs, but I would do mike to see actual data showing such remarking executed by the residential ISP, please. > > [JL] You may want to look at PCAPs or other data collected by various tests - like NDT (https://www.measurementlab.net/tests/ndt/) or one of CAIDAs platforms. [SM] Mmmh, the problem is that the claim in the NQG draft is rather specifically about "residential ISPs" and none of the sources appear all that useful in answering that question... > Here are some relevant papers that may be interesting: > - Exploring DSCP modification pathologies in the Internet, https://www.sciencedirect.com/science/article/pii/S0140366417312835 [SM] This contains, as far as I can tell mostly fixed access measurements from digital ocean locations to web servers, so does not cover the relevant "residential ISP" category. The mobile edge case is less clear, as the domain has expired and the MONROE project folded. The referenced paper does not even cover how many individual network operators participated... and while 107 mobile vantage points within the European MONROE platform sounds great, the relevant question is how many 'residential ISPs' does this set cover. > - On the Usage of DSCP and ECN Codepoints in Internet Backbone Traffic Traces for IPv4 and IPv6, https://ris.utwente.nl/ws/files/178150843/usage.pdf [SM] That shows even on 'the internet backbone' DSCPs are in use, but it seems unclear how to disambiguate DSCPs used by the backbone operator versus end points. Not sure this can actually help to verify the claim. > - Diffserv Measurement, https://www.cs.columbia.edu/~hgs/research/projects/diffserv/DS-report-12-17.pdf [SM] This used planetlab (http://www.planet-lab.org/php/top.php) which also has shut down in the interim, yet the paper states: "PlanetLab currently consists of 160 machines, hosted by 65 sites, spanning 16 countries. Most of the machines are hosted by research institutions, although some are located in co-location and routing centers (e.g., on Internet2's Abilene backbone)." This seems also not testing the set of "residential ISPs" that is of interest here. > - Exploring DSCP modification pathologies in mobile edge networks, https://tma.ifip.org/wp-content/uploads/sites/7/2017/06/mnm2017_paper13.pdf [SM] This seems to be the same 107 vantage points of the MONROE project also used in https://www.sciencedirect.com/science/article/pii/S0140366417312835 above, here the paper states: "We used the MONROE mobile platform. This provides dedicated infrastructure for Mobile Broadband (MBB) exper- imentation [18] and comprises over 250 mobile connected nodes distributed in four European countries: Italy, Spain, Norway and Sweden. Each node on the platform is connected to up to three MBB providers and often also to WiFi." Unclear how many Telcos that effectively covers, but given the limited set of countries that does not look all that representative to me, also this excludes (purposefully) fixed-line ISPs. > - Attacks Notification of Differentiated Services Code Point (DSCP) Values Modifications, https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=10314996 [SM] Mmmh,: "Three different networks were utilized for the analysis. It was ensured that each of the three networks included both a sender and a receiver. The Scapy tool was employed to create customized packets containing specific DSCP values, which were subsequently transmitted from one network to another. The packets that are received will be captured and subjected to analysis." Not sure this paper is pertinent here, sure they explore DSCPs in some form, but the residential ISP part seems not to be part of their focus. Thanks for sharing these links, however I am still not sure that these support the NQB draft's claim: "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," Look, I understand that DSCPs do not currently traverse the internet reliably and robustly, but that is not the same as a reliable neutering of NQB over not NQB-aware paths. Delegating safety tor accidental configurations (that are not really aligned with IETF recommendations) seems neither robust nor reliable to me. Regards Sebastian > > Jason > > > > >
- [tsvwg] NQB claim of DSCP- Sebastian Moeller
- [tsvwg] Re: NQB claim of DSCP- Livingood, Jason
- [tsvwg] Re: NQB claim of DSCP- Sebastian Moeller
- [tsvwg] Re: NQB claim of DSCP- Livingood, Jason
- [tsvwg] Re: NQB claim of DSCP- Sebastian Moeller
- [tsvwg] Re: NQB claim of DSCP- Vasilenko Eduard