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-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id CC72B3CB37 for ; Tue, 3 Oct 2023 03:15:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1696317355; x=1696922155; i=moeller0@gmx.de; bh=xOyF3b+/knI63X6aMfjx91DOcbhRXshGwi+OAYM5N9g=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=Lk7+HgYdVlVPW7AGBLKlnwIgEB7PyVjarew7IOckDfhkKJCDCs3DhOX36dHyg/1J4ozWU3+Qtag lK44ZYo4lWzeGWot1EWbUkR3+cuCy9go6QmuSNXHHgj6XJ5Od0N7L3rysvNp8ak8OeIfS/P/5AGXy DroN6aq9KLed/EqQSOolbhCO3CTWxTu6DAFU+nbFd8i+uIzwIn87qQB4JxIAI25f+zKWfZsAM1qC/ yR6O282nDj8gHtLk7DkdJi+b5LYOaiu9ijwxB00zK/fxsBH3x/FzQjJL8VA6px2JO9UnixjXvF1OI 0xbU3M2n/MGG6Ff87lZWATDOkj47dONj53kA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([95.116.82.136]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MvbBu-1reqRZ20Jy-00sd7u; Tue, 03 Oct 2023 09:15:55 +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: <31ec8bfe-4194-c9e2-5a3a-cd174cd1c7f3@kit.edu> Date: Tue, 3 Oct 2023 09:15:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <31ec8bfe-4194-c9e2-5a3a-cd174cd1c7f3@kit.edu> 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:WbHstlKrcKInnC5yQYTElj7wmgOBTLsnXX0vLr/mcPEN0cNMxXK 10PHwNVm/ps5hNGC+jSIY9Wi/xXA7mIyxSIWLpl6oxEPyMlOGCHSRE6nv79wQB5nGqGGBeY i7ljo7Npz5B1g7Uue9MIMInaIlvWDC+V9kpQRo/2Ap2xIA148iHnXIMqV+xkSLFQDpYTxBx UWFXVeNc8weIu8UYlexyg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:FFVjWeMYAy4=;RJgazxi+a1TYsAA2oxbWttwsrz+ 2Y2OqIFLjrresFiQeai1TiNp5rwvsQfbA/UW61CyvGjajyQJkgcrbzdFX6i66zrVUm6he1fFm elaUUEUqTBNS5rswySCmPjB31AEIFddvJ9yxcyA//Pflz0rkfmY6FnQu9MJxWhYeF7nKKhZNZ 0PjyedrmdIoQ4QvSQ5huYC+zmNDBGTWUHXrc1hz2ewe4wDc+MSM6F2HvZbHX5jkN+CTf1BUGs UsLY94k+D+BeOI8QDa5lRkX0S/PY6S7SP3FRV/Z2vSUYFade5xv9f16d77SGmnldaDeC6ffEF OH1g6JbqMDnftKl4V43XRE6zspM0bbfzgoXyHmZiSq+jmaabKhYBj3iKPyWYyHo2gW+1G0c68 pFFTJRflZA2vhcAc5KFCs+SXbIL0tZR/TJrEeZ+z017zKobcjY+hOH1ZfnDKPoU6MMErYWY3H AzZjsWLqzPTREIjbqG4CeOlaiQaoLSOEYtlbCnexatYtHHr364Om3M0TTGNkjKks/bHvWJdmw O4K6d9RmbxncvIBStLWZD13r9Iq5/2MtVdO6na/vec0K7/uvXavcxoQMv1SP9hpo/XBThVBlc 9M5DUEUIb2cWIHZ+TYI081fZYRiXPFBYUv73jXxASJ/9tNQe+dMswFaCtdPVzun1l3xoVme3y JX71jXqy6yFRydi3bz6fFmO+nj/5UNbEp/IeHqsPbyj/ff+9SUzCS21lt8uzPfVxCbh0nKqxr K8LVWJOUSAwyhv3/26U0OAg3pW97YxNk1BjAV4WIJZXp/Zu1JVY6gnvegEHdSBlr1aGmRi8F1 S2mcqnbKAoszSESFp36InQyqDf9zrx/dlnTW+YwdSw0yqmDVf50qTZIhOMN0M53xC0o14vBJH g95rAkxTdid95utKagKEXBIII56SXdqv2HAs4zX9grBztcJhN+8oYU2sJWO8ztaJPOiiWBRR0 y1Bpsg== Subject: Re: [NNagain] Some backstory on the nn-again mailing list 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: Tue, 03 Oct 2023 07:16:00 -0000 Hi Roland, > On Oct 2, 2023, at 14:36, Bless, Roland (TM) via Nnagain = wrote: >=20 > Hi Dave and all, >=20 > my view is that a net neutrality purist's view like > "all packets, contents, and services must be transported equal" > does not make sense from a technical viewpoint as there are services > such as VoIP and other interactive applications that require > prioritized forwarding to work properly [*]. >=20 > However, there are ways to do it correctly: >=20 > 1.) the provider should be transparent about which packets/services = are > handled differently from best-effort. >=20 > 2.) the user should also have a choice, e.g., in case an ISP = prioritizes > VoIP packets, other VoIP providers and VoIP applications should also > be able to use this preferential treatment, ideally, the end-user can > "signal" which applications should get the better/worse treatment. > Furthermore, some other network management techniques must be = permitted > to deal with DDoS and other forms of attacks. > The old FCC rules from 13.4.2015 were quite reasonable, which I would = summarize as: > * No Blocking > - No blocking of lawful content, applications, services, and = non-harmful devices > * No Throttling > - No provider-based throttling of lawful content, applications, = services, and non-harmful devices > * No paid Prioritization > - No preferential treatment of certain lawful content over other = lawful content by payment >=20 > * Goals > - ISPs should not disadvantage users or edge providers > - Achieve larger transparency > - Permit reasonable network management -> without direct commercial = intents >=20 > Since I'm not a U.S. citizen I did not follow any recent debate on NN, > but I found the above rules quite sensible. > However, the EU rules were actually worse as they left a loophole > in EU regulation 2015/2120 article 3 paragraph 5. [SM] Here is the relevant text: "5. Providers of electronic communications to the public, including = providers of internet access services, and providers of content, = applications and services shall be free to offer services other than = internet access services which are optimised for specific content, = applications or services, or a combination thereof, where the = optimisation is necessary in order to meet requirements of the content, = applications or services for a specific level of quality. Providers of electronic communications to the public, including = providers of internet access services, may offer or facilitate such = services only if the network capacity is sufficient to provide them in = addition to any internet access services provided. Such services shall = not be usable or offered as a replacement for internet access services, = and shall not be to the detriment of the availability or general quality = of internet access services for end-users." After reading that I thought it depends on how the regulators = are going to police and interpret the last sentence. My gut feeling = always was that this is intended for stuff like offering real-timish = deterministic networking for e.g. autonomous vehicles. While I am not = sure 'autonomous vehicles' in dense traffic areas on earth are that = great an idea (unlike on Mars, where they are an excellent idea! but = there traffic density is not an issue, nor are pedestrians) I am not = aware that any ISP so far has actually made use of this option, so it = seems unclear to me whether this will end up a real loophole or not. Are = you aware of any existing use or abuse? Regards Sebastian >=20 > Regards, > Roland >=20 > [*] At least I know the case of a large German ISP and VoIP > provider that needed to prioritize VDSL VoIP traffic by using DiffServ > marking from an RTP relay in downstream direction. Without DiffServ > prioritization VoIP quality was not satisfactory during simultaneous > up-/downloads as the one way speech delay exceeded 110 ms. > However, that preferential treatment is only used for their own VoIP > service (and they are providing the RTP relay server), which is > problematic from a net neutrality point of view as it should > be usable for other VoIP/WebRTC traffic from other providers, too. >=20 > Regards, > Roland >=20 > On 01.10.23 at 19:15 Dave Taht via Nnagain wrote: >> I am pleased to see over 100 people have signed up for this list >> already. I am not really planning on "activating" this list until >> tuesday or so, after a few more people I have reached out to sign up >> (or not). >> I would like y=C2=B4all to seek out people with differing opinions = and >> background, in the hope that one day, we can shed more light than = heat >> about the science and technologies that "govern" the internet, to >> those that wish to regulate it. In the short term, I would like = enough >> of us to agree on an open letter, or NPRM filing,and to put out a >> press release(s), in the hope that this time, the nn and title ii >> discussion is more about real, than imagined, internet issues. [1] >> I am basically planning to move the enormous discussion from over >> here, titled "network neutrality back in the news": >> = https://lists.bufferbloat.net/pipermail/starlink/2023-September/thread.htm= l >> to here. I expect that we are going to be doing this discussion for a >> long time, and many more issues besides my short term ones will be >> discussed. I hope that we can cleanly isolate technical issues from >> political ones, in particular, and remain civil, and factual, and >> avoid hyperbole. >> Since the FCC announcement of a proposed NPRM as of Oct 19th... my = own >> initial impetus was to establish why the NN debate first started in >> 2005, and the conflict between the legal idea of "common carriage" vs >> what the internet was actually capable of in mixing voip and >> bittorrent, in >> "The Bufferbloat vs Bittorrent vs Voip" phase. Jim Gettys, myself, = and >> Jason Livinggood have weighed in on their stories on linkedin, >> twitter, and elsewhere. >> There was a second phase, somewhat triggered by netflix, that = Jonathan >> Morton summarized in that thread, ending in the first establishment = of >> some title ii rules in 2015. >> The third phase was when title ii was rescinded... and all that has >> happened since. >> I, for one, am fiercely proud about how our tech community rose to >> meet the challenge of covid, and how, for example, videoconferencing >> mostly just worked for so many, after a postage stamp sized start in >> 2012[2]. The oh-too-faint-praise for that magnificent effort from >> higher levels rankles me greatly, but I will try to get it under >> control. >> And this fourth phase, opening in a few weeks, is more, I think about >> privacy and power than all the other phases, and harmonization with = EU >> legislation, perhaps. What is on the table for the industry and >> internet is presently unknown. >> So here we "NN-again". Lay your issues out! >> [1] I have only had one fight with the FCC. Won it handily: >> = https://www.computerworld.com/article/2993112/vint-cerf-and-260-experts-gi= ve-fcc-a-plan-to-secure-wi-fi-routers.html >> In this case this is not so much a fight, I hope, but a collaborative >> effort towards a better, faster, lower latency, and more secure, >> internet for everyone. >> [2] https://archive.org/details/video1_20191129 >=20 > _______________________________________________ > Nnagain mailing list > Nnagain@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/nnagain