From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 847C63CB37 for ; Wed, 11 Oct 2023 16:49:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1697057343; x=1697662143; i=moeller0@gmx.de; bh=fYxoFMD0NatSzRg4NJcb7FNNSw13RJG9Y+mLxxPEfQk=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=DlYxXEKGj2nQHHDfeM/Lf24Wf/Ghd04PfJP1xlb/v0BJ79SNVLtUrf42MFFEeOuYv/6vfi6TEP/ aI2y3CH0Y4fhH5tgm2HYC4Dr644cruwqPTxmaCXXf4hq51I6gG5G/tkM8eyPedb22AxuusqT2yKQO 0G59lPPXRdNKMQikVvMf21FdkyaJiCMfi9CvbegrwZDeDOGSOJe5Mw5n8TjzQ3CHsv8oxpJuiXjmx 0BmkmhRtBsAt/B4nPQHaosLb7LtNJ8CPCs0Cl5L986SEmvQf/fboU5Cm9eJhik7jMMiue+kaqOasZ yZcEcahO1CUj++iDc+76C9cRFKss406IXYVQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([84.157.45.139]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MIdiZ-1qkxcx3hRN-00Ecip; Wed, 11 Oct 2023 22:49:03 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) From: Sebastian Moeller In-Reply-To: Date: Wed, 11 Oct 2023 22:49:01 +0200 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , Nick Feamster Content-Transfer-Encoding: quoted-printable Message-Id: References: 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.3696.120.41.1.4) X-Provags-ID: V03:K1:qClinpUDlbdt+z3QJDSw/yQpjlfXR4oXp+pzDZYiYRdcQJ4TxPt Yi2vT/LqI589bSU/d82lEOS6yF34McQDf5ow2Q+1+qG1csK+GZvqahRziJHdLon7HWRkBwJ yjBmRU4gclLy2rGtv7Nf+/u9ksT/+2/7JPWXo1dBBHe98u+lLhDHdyUbbTkIKwBuh2QQQZj UA7Idr1of2vz8WAGph1TA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:85ugKJlFUbE=;ts9kuLKoTDTDxoNpvWhxfhA/pjn Uu3bCamBjRzOV2D+Dk+rL12bUrxy3FJcXtrGVmMHRpByVrCuW6F3NpMNTzL8uGPC7iKBdRqtf 8vLyUCX5YlCZ/MpWgCLY1ZX+O/hxAYWNO//kFIC816SKXnBJzIkYn/9fuKIL65T8sFqwmGOt8 v+cPhQUp2pKwUQ7ZjOYJm3mmNlmSA/0KRUsaehACzV6pJsCznC0w2Vl/JMV2EySHob5R/E7wj ZbGHDgQkAbUkbqUSpvuFqoqXRV6MZ7KRATxzF/3joHmoGGNz4c7G2JGJ5exHntryIdL2Wjdsw 4J/vjGu2zNIdlECJdv01gnOJMGLTEyYVtu4OdAr9OXqRmpMt2g5tn1ChODS0709lLD9SwNDcT GGLZTzMxZlTU8dMYbSQJjbI4tJAPQubsAwWr24igrrP2Z2sgW3q5w6r1ruoqYMCNfWR538Lg9 SAkM2ffZo3MLUMxjCaJqPwMcR5rKxrKq1R94cD1Iofde4sHs+dlw4e+d6nUT8qyWNLq+UI5y2 KjnSmrMaVgK0gL3n4sdObdmoxYhhA92jHJt6p7NzKofnjm+H2+l//czv1Nedjg6SHT7E/E2s5 6ampLQrVCmwcbRfi5MUmI0yLmgFnM1HZWJ5CfAHmu/+gM88+6JhEmbKzfbYGVFeQZh42sF0MI jkcvz2iy7HYTSeLIiuriommPJyfpkMpg5WyBXQu3yGwnPvntSlBoI74R7WQI8MSuUEGmjhBLS NwPssAAe+o/nppwIkR5ANP5qknWpB22osPabwh5N/ROQ2OT7Mfnag2b8iV5TbBhY5Xua+Bzlb 1arydrwizw/nNWFMplWjX+tjg28jB2/oeVlXGS4o5LVwBXGpOZx+5lqvDR6vEgf+DmkEu4+hv ip6ex6N3f+rVLCP2+nl+Ba7Ooa7dzLxREIenUYg0MVGUnf5BMSXff9zejyd0kB4AVidbF5BeK PY9owvkXQgybLWj4ZAdRJBtwLBI= Subject: Re: [NNagain] Internet Education for Non-technorati? 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: Wed, 11 Oct 2023 20:49:08 -0000 HI Dave, > On Oct 11, 2023, at 20:06, Dave Taht via Nnagain = wrote: >=20 > I think y'all are conflating two different labels here. The nutrition > label was one effort, now being deploye, the other is cybersecurity, > now being discussed. >=20 > On the nutrition front... > We successfully fought against "packet loss" being included on the > nutrition label, [SM] Not wanting to be contrarian, but I consider a number for = random packet loss relevant. The Matthis equation allows to predict the = maximal achievable TCP rate over a link with random packet loss and so = this has clear bearing on a link's utility. I do agree that the TCP = packet loss during an actual speedtest is much less interesting, but = random packet loss over a quiet link is an important characteristic... I = learned this the hard way when my ISP started to route my access link = occasionally over a bad router with ~1% random packet loss (I managed to = get my ISPs attention and over the course of a few months they managed = to isolate and fix the issue, but I never got a post-mortem of what = exactly had happened, all I know is that they dragged one of their = hardware vendors into the diagnostics). > but as ghu is my witness, I have no idea if a formal > method for declaring "typical latency" was ever formally derived. [SM] The easiest really is: set up reference servers outside of = all eye-ball ISP AS and distribute a measurement client that will = measure against those servers... if you want to improve upon this, = locate measurement servers into the AS of the most important transit = providers and randomly select one for each test (and report the endpoint = location as part of the results). Best Regards Sebastian >=20 > = https://www.fcc.gov/document/fcc-requires-broadband-providers-display-labe= ls-help-consumers >=20 > On Wed, Oct 11, 2023 at 10:39=E2=80=AFAM David Bray, PhD via Nnagain > wrote: >>=20 >> I was at a closed-door event discussing these labels about two weeks = ago (right before the potential government shutdown/temporarily averted = for now) - and it was non-attribution, so I can only describe my = comments: >>=20 >> (1) the labels risk missing the reality that the Internet and = cybersecurity are not steady state, which begs the question how will = they be updated >> (2) the labels say nothing about how - even if the company promises = to keep your data private and secure - how good their security practices = are internal to the company? Or what if the company is bought in 5 = years? >> (3) they use QR-codes to provide additional info, yet we know = QR-codes can be sent to bad links so what if someone replaces a label = with a bad link such that the label itself becomes an exploit? >>=20 >> I think the biggest risks is these we be rolled out, some exploit = will occur that the label didn't consider, consumers will be angry they = weren't "protected" and now we are even in worse shape because the = public's trust has gone further down hill, they angry at the government, = and the private sector feels like the time and energy they spent on the = labels was for naught? >>=20 >> There's also the concern about how do startups roll-out such a label = for their tech in the early iteration phase? How do they afford to do = the extra work for the label vs. a big company (does this become a = regulatory moat?) >>=20 >> And let's say we have these labels. Will only consumers with the = money to purchase the more expensive equipment that has more privacy and = security features buy that one - leaving those who cannot afford privacy = and security bad alternatives? >>=20 >> On Wed, Oct 11, 2023 at 1:31=E2=80=AFPM Jack Haverty via Nnagain = wrote: >>>=20 >>> A few days ago I made some comments about the idea of "educating" = the >>> lawyers, politicians, and other smart, but not necessarily = technically >>> adept, decision makers. Today I saw a news story about a recent FCC >>> action, to mandate "nutrition labels" on Internet services offered = by ISPs: >>>=20 >>> = https://cordcuttersnews.com/fcc-says-comcast-spectrum-att-must-start-displ= aying-the-true-cost-and-speed-of-their-internet-service-starting-april-202= 4/ >>>=20 >>> This struck me as anecdotal, but a good example of the need for >>> education. Although it's tempting and natural to look at existing >>> infrastructures as models for regulating a new one, IMHO the = Internet >>> does not work like the Food/Agriculture infrastructure does. >>>=20 >>> For example, the new mandates require ISPs to "label" their products >>> with "nutritional" data including "typical" latency, upload, and >>> download speeds. They have until April 2024 to figure it out. I've >>> never encountered an ISP who could answer such questions - even the = ones >>> I was involved in managing. Marketing can of course create an = answer, >>> since "typical" is such a vague term. Figuring out how to attach = the >>> physical label to their service product may be a problem. >>>=20 >>> Such labels may not be very helpful to the end user struggling to = find >>> an ISP that delivers the service needed for some interactive use = (audio >>> or video conferencing, gaming, home automation, etc.) >>>=20 >>> Performance on the Internet depends on where the two endpoints are, = the >>> physical path to get from one to the other, as well as the hardware, >>> software, current load, and other aspects of each endpoint, all = outside >>> the ISPs' control or vision. Since the two endpoints can be on >>> different ISPs, perhaps requiring one or more additional = internediate >>> ISPs, specifying a "typical" performance from all Points A to all = Points >>> B is even more challenging. >>>=20 >>> Switching to the transportation analogy, one might ask your local = bus or >>> rail company what their typical time is to get from one city to >>> another. If the two cities involved happen to be on their rail or = bus >>> network, perhaps you can get an answer, but it will still depend on >>> where the two endpoints are. If one or both cities are not on their >>> rail network, the travel time might have to include use of other >>> "networks" - bus, rental car, airplane, ship, etc. How long does = it >>> typically take for you to get from any city on the planet to any = other >>> city on the planet? >>>=20 >>> IMHO, rules and regulations for the Internet need to reflect how the >>> Internet actually works. That's why I suggested a focus on = education >>> for the decision makers. >>>=20 >>> Jack Haverty >>>=20 >>> _______________________________________________ >>> Nnagain mailing list >>> Nnagain@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/nnagain >>=20 >> _______________________________________________ >> Nnagain mailing list >> Nnagain@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/nnagain >=20 >=20 >=20 > --=20 > Oct 30: = https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html > Dave T=C3=A4ht CSO, LibreQos > _______________________________________________ > Nnagain mailing list > Nnagain@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/nnagain