From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B7BFB3B29D for ; Sat, 9 Mar 2024 10:04:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1709996661; x=1710601461; i=moeller0@gmx.de; bh=RvtCBEKOdQXz6hXRaZKWXlvQ0iJxEQWqjZI9WzkEgrY=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References: To; b=NqpPnpw4oePdC0YBO5oTX14TGCv3AGi6XGeQ1xWXkZRMvSz8zcM6kqO+7bMCFcbB LcPFs6ZsVZD7w1rHG8eOkKgI3P1OO0ea0tigIbB1irZ4VJLFfNIQE54Hhbo4Tmlll siWGK5TD91YfWnJBmqA7934AaO4aQZ9uADGd/i2ZPbDcWIkRUGxDhBN2JBr4Ck4hP ypukdZX7ckiu6QZpOEF/okzSj+W4Y3sQ2Bh/Jz2Ab/gqXCcviV0C/NUdxaSMibNSU 2Iplc6XeD7E9nJ7i3JakExwzL4UGyvBf8KbxhT7aBBshsMN1U1MAW/5qCR5IJ3lov eo69MwXF2evdK47IpQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([95.116.156.200]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MTRMs-1rFAHR2UfM-00TkcY; Sat, 09 Mar 2024 16:04:21 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) From: Sebastian Moeller In-Reply-To: <636F01F7-54FB-41A6-957F-99D114A72B6A@comcast.com> Date: Sat, 9 Mar 2024 16:04:09 +0100 Cc: "Livingood, Jason" , "Douglas Goncz A.A.S. M.E.T. 1990" Content-Transfer-Encoding: quoted-printable Message-Id: References: <8op80p47-77p9-p9s3-6o32-7s93o3ssp653@ynat.uz> <636F01F7-54FB-41A6-957F-99D114A72B6A@comcast.com> To: =?utf-8?Q?Network_Neutrality_is_back!_Let=C2=B4s_make_the_technical_as?= =?utf-8?Q?pects_heard_this_time!?= X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Provags-ID: V03:K1:7Q807f3pbwfKBXsKErC1ZnpJwphh9+zdeAo7yTpsXLY5vDjkGWp vELgD/xMTJE4XSd35tmy8Gguny9ZJn661ZVsVISugqpGEFWmNwJJjAbMntx26nd84HP8NZl KXuHGTldbPZNHSxfeTWiv1ZwAEgPYzjhBQStmq9/gvxGgicGHHmRw09/P9B80OSgO5zXfFh qIxJEXxNLKHCaadIWr05g== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:nSCm1rt4GTc=;QYodoo/XButUe4oEa8ZnNlyWA3o W8VxZQxY2Fc6eClQ+SorHUaNfJ4zqZ2YZ5ROklnyie79hjsKlVOTZ+vM6ePtO569sEaPdUkCn G1Tkj5l7NTfFaB1yoi6u5StUEOdmKUl0+kPTGSB+v7G0yrwwDGhjFEJA2dSbjSJRoXtM8Twar 18HNJQjRo1E/iMzfmbLuNU92s1LpYT76fnLa3qnmFDw12Zz4lVAI8jK7fBQJ/7DNgUZ6H1Ix8 9NPI+QlJXzHBqU96K5TffV57Cn2YZfN0GG+Q27CXYswAWp0hAXRMyG72NTzfUIgWiXetowRoy ojY9C9lJwWuM+5FwMtTQc1fu0EqXDly256h4FQ95ALxdeVr4p1Lx2WTSDVyDj3+tndsS7T78o EIC+P2FrXzNK5XzrBVuqy2Z8whxd8neuvMYUQjWkSh56PcvpLB9p+Q4j5L2+yAVxy1q3IpDaL srWaCbC8lSvy9l/JEdZFvGpX3AHyS8bfrN/d5Zto6Jl1bpruVajYGpg7SHnvp3+KOi7Wmro1W pQGsMshLL7/2+KuXA8CummZvNRpXZ4cyY4d4/wD6LHTdpDJqoV4V9QCzn0cRyAr7PMSPItT0h QBjDG7mU4Ta5lcdyqlzdfZnlMPxlU3n29Ghl153hLcMDHUmlcXgGFnbdFVhhxmeRZwxPcs4jQ gR6NMM64GhpSUdAmbXOhuP4tgXMbc1pHdSCSdQKTtKir48m8VwlywmSxJU6Drq5vwtTCOfy02 ykHKOFWTXgmGIbvKuHOJTJHypnX+gGkmyg/nM2u+VIB1gXhTX1Dejg5+CLIVXEEL29DFN1g12 OqS92AcjnYycXLHSV4CaXWXqoe4pofWQzXq8w1Xg4QvJc= Subject: Re: [NNagain] Flash priority X-BeenThere: nnagain@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: =?utf-8?q?Network_Neutrality_is_back!_Let=C2=B4s_make_the_technical_aspects_heard_this_time!?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2024 15:04:29 -0000 Hi Jason, > On 9. Mar 2024, at 15:38, Livingood, Jason via Nnagain = wrote: >=20 > On 3/8/24, 22:02, "Nnagain on behalf of David Lang via Nnagain" = on behalf of = nnagain@lists.bufferbloat.net > = wrote: >=20 >> In practice, priority bits are ignored on the Internet. There are no = legal > limits on what bits can be generated, and no reason to trust priority = bits that=20 > come from a different network. >> As I understand the current state of the art, best practice is to = zero out > priorities at organizational boundries >=20 > [JL] Quite true: each network tends to use DSCP marks on a = private/internal basis and so will bleach the DSCP marks on ingress from = peers. This will, however, change with the upcoming IETF RFC on = Non-Queue-Building (NQB) Per Hop Behavior - = h++ps://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb. [SM] In all respect, that is wishful thinking. Just because an IETF RFC = states/recommends something does not mean it actually is implemented = that way in the existing internet... Current in-effect RFCs already = recommend that ISPs should not change DSCPs that they do not need to use = for their own PHB-needs but simply treat them to default forwarding, but = that is not what ISPs actually do. Case in point, a big (probably the = biggest) DOCSIS ISP in the USA had been remarking a noticeable fraction = of packets to CS1 for years (which at a time was defined to mean = background or lower priority and is treated as such by default WiFi APs) = causing issues at end users' home networks. (Said ISP, to its credit, = did fix the issue recently, but it tool a few years...). Just becyause something is writen in an RFC does not make it reality. = And given the hogwash that some RFCs contain, that is not even a bad = thing per se. (Examples on request ;) ) > And I can report that we at Comcast now permit DSCP-45 inbound for NQB = packets, in case developers would like to experiment with this (we just = finished updating router configs last week for residential users on = DOCSIS; FTTP and commercial are still in process). [SM] Since I have your attention, if I try comcast's bespoke = networkQuality server (from your L4S tests): networkQuality -C https://rpm-nqtest-st.comcast.net/.well-known/nq -k -s = -f h3,L4S I saw ECT(1) marking on my egressing packets, but none on the ingressing = packets... that does not seem to be in line with the L4S RFCs (giving = another example why RFC text alone is not sufficient for much). = (Sidenote: if all L4S testing is happening in isolated networks, why = wait for L4S becoming RFCs before starting these tests?) >=20 >=20 >=20 >=20 > _______________________________________________ > Nnagain mailing list > Nnagain@lists.bufferbloat.net > h++ps://lists.bufferbloat.net/listinfo/nnagain