From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 D7DE33B29D for ; Mon, 2 Oct 2023 02:34:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1696228481; x=1696833281; i=moeller0@gmx.de; bh=o260oohrykUK+PhP+cmph9Cz88trjWl3xLjaBBSrAnw=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=Hg0uPNbb6PwSKftzI1MOw7hKPx46Atj7D0iHXZOymtTboUkoauXE36LruVIZ4+gFbYMHJzlnJmw 52Xlh89i+oD3J1DeusmUcoHqDa2nOfNcl0k6nEfQRMcTdjUE+PJ6pluQiD3+0j8v+75zsnj7smZ4p dCFv70eouiICFcs/jBFTOJQo5t3l7CwBjlf8ca+CXMJ2G+/023zK+r4l1OiuzbDQTCmO/oHrq1qVO WlsKXtpaZre1RUx2qgA+eA/JgaKTBJDzd4Hu0AP7+n1XWryXSYWcOHVqZj43a6z911AO6CyW3wE7r x3v15hoSoYup5wwReJx6XPbnSACbmbjPJMkw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([77.0.37.4]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MUGiJ-1rDDzW3Bop-00RETa; Mon, 02 Oct 2023 08:34:41 +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: Mon, 2 Oct 2023 08:34:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <788420A6-081F-44DE-A58E-CF99A3508A99@gmx.de> 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:rPO2U9nraXW7q39EVlHKtwAx8Gnntc+R2jQ+VbMPw2bwiuBs2x4 zZhySZmGhmxAsuj7Kgv6tDlj4XlJSG66lc9Fzdb7jBRdOY9S8r/i3mkpv+0DpPMQ/Q5rtl8 L1nj6/tezYNOZtDx0PFuplIT5T9OqY8fSkFeupsPHlSjOpCsDmpGM71MPwk6MyWzTd5el8M +kb6U8kcO8u91qhKNDNUg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:P2mW5dPL4+U=;5PbZ9ybocteoRB+Hyj1ueuRjZcB VjF2aVCWdhKry2xZH9Ok9eMwyQbT4DQHQXDywTvMf6a70Dnabx5g09E7VK0RgmzH0VgMEwEuZ /78M3qjAnIYUlYlwKupJSvBHEiy8j7sJsyCozQXj3o/bCrMN5mg3d14PVMs1xIK4BdGEEp39L DUrEDmEtbhOHkMsv5ZWWVZ1yLglY56Abpj9gV3xCiA1o5exghJnfEHkqi73laIFU4yEnTMWZY 9YcblOY76dP4bRr9auWJwesumhYYIZXA+lozm5+36aZUXUP5+tM+Cd0GKqKXZ5z71tyHYz4yt 8mh2V8HxDAfd17pI8zKy7bZS3f6jAJU1NiTU87v+f2C0mLYqSavL4Q342RqZ8OEa55lksSePv +jI1OLZMjXWu6rKdrgWELkGW65T1KLjLd9vvUzUYlhm+D9WaFdYZp5q86BG3jh3361SEeULa1 dJWAx/CWXO8iQXUOtR7oyctrq4YdRGHHRzFEwofJgBnn0rlTntWLRmLP5k7ugndphi2KqiL2n uB2beesVTEi9BE9I1IfZfxCOlzAC6jzRuweiT+nkAnFoVi4LpZU8uNop9Pt5Zwfpi5HOGhfGI Ub21pNCVyGLG9QUDjEAf3Je+wfcJvBPRbAuh77aC3mUl/kCSd3R6xp5EaFmX13zFW9y3ino0E E3yfbBLctrq3A5Kav6fJ/UvGJil+i+WIscdpaSgC6dOqXxovT90e9Wlcthj9VUv9kt/AqDRi1 QjfQr6IikOnXZncPRoCxUVSUuc4VohsMxJLp4OpS8f6eB8Vpcarl738ghPo/fa94aFTKe/3Uc r0IHxD8YTyoToO4x2tmsFCzUepBbbekvyGrM8CmUIN0aeV8wSUhyMMmB4hop6tImIJn9W2LpU s/nX7lxkBzOnBzg7Q3boRGDk2ksGnjhimHVFM+fk5RG4nD9lQFCI9qxTlHbzNlTLkV8dF4Qyk 3mIptA== Subject: Re: [NNagain] On "Throttling" behaviors 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: Mon, 02 Oct 2023 06:34:44 -0000 Hi Dave, > On Oct 1, 2023, at 21:51, Dave Taht via Nnagain = wrote: >=20 > I kind of expect many, many forks of conversations here, and for those > introducing a new topic, > I would like to encourage using a relevant subject line, so I have > changed this one to suit. >=20 > On Sun, Oct 1, 2023 at 11:57=E2=80=AFAM Frantisek Borsik > wrote: >>=20 >> OK, so I will bite the bullet! I have invited Ajit Pai and Martin = Geddes to join us here and let's see if they still have some time and/or = even stomach for current round of NN discussion. >=20 > Honestly I was hoping for some time to setup, and even perhaps, have > enough of us here > to agree on one of the definitions of NN, to start with! >=20 >> Anyway, here is my bullet. I will argue with Martin, that - Net = Neutrality CAN'T be implemented: >=20 > You meant "argue along with" rather than "with". I know you are not a > native english speaker, but in the way you said it, it meant you were > arguing against what he described. >=20 >>=20 >>> Whilst people argue over the virtues of net neutrality as a = regulatory policy, computer science tells us regulatory implementation = is a fool=E2=80=99s errand. >>> Suppose for a moment that you are the victim of a wicked ISP that = engages in disallowed =E2=80=9Cthrottling=E2=80=9D under a =E2=80=9Cneutra= l=E2=80=9D regime for Internet access. You like to access streaming = media from a particular =E2=80=9Cover the top=E2=80=9D service provider. = By coincidence, the performance of your favoured application drops at = the same time your ISP launches a rival content service of its own. >>> You then complain to the regulator, who investigates. She finds that = your ISP did indeed change their traffic management settings right at = the point that the =E2=80=9Cthrottling=E2=80=9D began. A swathe of = routes, including the one to your preferred =E2=80=9Cover the top=E2=80=9D= application, have been given a different packet scheduling and routing = treatment. >>> It seems like an open-and-shut case of =E2=80=9Cthrottling=E2=80=9D = resulting in a disallowed =E2=80=9Cneutrality violation=E2=80=9D. Or is = it? >>> Here=E2=80=99s why the regulator=E2=80=99s enforcement order will = never survive the resulting court case and expert witness scrutiny: >>=20 >>=20 >> = https://www.martingeddes.com/one-reason-net-neutrality-cant-implemented/ >=20 > Throttling, using DPI or other methods, is indeed feasible. It is very > straightforward to limit flows to or from a given set of IP addresses. > However, there are also technical limitations, based on for example, > the underlying connectivity of a path be it one gbit or 10, which > would also show a customer problem in unwinding the difference between > intentionally throttling and merely being out of bandwidth across that > link. A lot of the netflix controversy was generated because netflix > suddenly ate far far more bandwidth that anyone had provisioned, and > was ultimately addressed by them developing and making easily > available a caching architecture that could be located within an ISPs > borders, saving an enormous amount on transit costs. The rest of the > computing universe followed with enormous numbers of CDNs from the > bigger services being built out in the years following. >=20 > In part I kind of reject a few older arguments here in the face of > subsequent, technical improvements on how the internet works. >=20 > I had many discussions with martin back in the day. The reasoning in > this piece is pretty sound, [SM] So to me this really looks like a Nirvana fallacy, that = tries to invoke the halting problem of all things and deduces all = regulatory action to be futile. But in the end really proposes what NN = is really all about, making sure end-customers end to end experience is = not artificially biased. I guess I am misunderstanding his point and = would appreciate be set straight here ;) > except that "fairness" can be achieved via > various means (notably flow (fair) queueing), and it has always been a > (imperfectly implemented) goal of our e2e congestion control > algorithms to ultimately converge to a equal amount of bandwidth at > differing RTTs to different services. [SM] This is a good point that makes me reflect my position on = this topic a bit; because I have been living in a flow queued = environment for over a decade now, I fail to see how achieving that (on = a "good enough" level) should be unachievable. > My principal kvetch with his work was that every blog entry during > this period making these points then ended up linking to a "Quality > Floor", called "delta-something", a mathematical method that was > ill-documented, not available as open source and impossible, for me, > at least to understand. The link to that solution is broken in that > link, for example. That quasi-mystical jump to "the solution", I was > never able to make. [SM] Looked from high above his argument really seems to say, NN = measurement should not focus on per-network configuration but on = conparung end to end performance/experience, something I guess nobody = disagrees with all that much? >=20 > I believe something like this method lives on in Domos=C2=B4s work = today, > and despite them filing an internet draft on the subject ( > https://datatracker.ietf.org/doc/draft-olden-ippm-qoo/ ) I remain > mostly in the dark, without being able to evaluate their methods > against tools I already understand. [SM] Their telemetry method, really is one that is only = achievable for an ISP inside their own network, as clever as it appears = to be as unsuited to end-to-end measurements over the internet they seem = to be as almost no path will be fully instrumented... > I like the idea of what I think a "quality floor" might provide, which > is something that fq-everywhere can provide, and no known e2e > congestion control can guarantee. >=20 > I would like it if instead of ISPs selling "up to X bandwidth" they > sold a minimum guarantee of at least Y bandwidth, which is easier to > reason and provision for, but harder to sell. [SM] Independently of what an ISP promises, not all paths will = be able to carry that much capacity at any one time and often not for = the fault of that ISP. The way the German regulatory agency (BNetzA) = tried t tackle this issue is by requiring foremost that the contracted = rates can be measured against a set of reference speedtest servers = operated for the BNetzA and located at one/some of Germany's largest IX = (though ISPs can also opt for private peering with the AS hosting the = servers, which IMHO is sub-optimal). The EU regulation also makes an = exemption for things out of the ISPs control, say if Notflix [sic] would = decide to not serve ISP A than ISP A can not be faulted for having = shitty connectivity to Notflix, even if Notflix would offer excellent = access for excellent $$$$. Not saying the EU regime is perfect, but it = at least covers a lot of ground and seems all in all balanced between = end-user, ISP and content provider perspectives. >=20 > Instead: >=20 > In the last 14 years I focused on restoring correct behavior of the > well-defined congestion controls of the internet, first documented > here: https://ee.lbl.gov/papers/congavoid.pdf and built on the > decades since, while many others made enormous advances on what was > possible - packet pacing, for example, is a genuine breakthrough in > how multiple services from multiple providers can leave sufficient > space for other flows to co-exist and eventually use up their fair > share. [SM] Yes, we as a community, made great strides on the technical = side, but that did not magically remove all NN issues. For example = mobile carriers in the EU opted for tilting the playing field by = zero-rating some selected services on their volume-limited mobile = networks, something that was finally deemed in violation against the EU = rules exactly because ISPs are required to not "pick winners or loosers" = but to offer unbiased access to the internet. >=20 >>=20 >> I hope you will read the link ^^ before jumping to Martin's = conclusion, but still, here it is: >>=20 >>>=20 >>> So if not =E2=80=9Cneutrality=E2=80=9D, then what else? >=20 > This is the phase where his arguments began to fall into the weeds. >=20 >>> The only option is to focus on the end-to-end service quality. >=20 > I agree that achieving quality on various good metrics, especially > under load, is needed. The popular MOS metric for voip could use some > improvement, and we lack any coherent framework for measuring > videoconferencing well. >=20 >>> The local traffic management is an irrelevance and complete = distraction. >=20 > I am not sure how to tie this to the rest of the argument. The local > traffic management can be as simple as short buffers, or inordinately > complex, as you will find complex organisations internally trying to > balance the needs for throughput and latency, and for example, the > CAKE qdisc not only does active queue management, and FQ, but > optionally allows additional means of differentiation for > voice/videoconferencing, best effort, and "bulk" traffic, in an > effort, ultimately to balance goals to achieve the "service quality" > the user desires. Then there are the side-effects of various layer 2 > protocols - wifi tends to be batchy, 5G tends towards being hugely > bufferbloated - PON has a 250us lower limit, cable [SM] I think his argument is that a sufficiently malevolent and = genius ISP might be able to spread a discriminatory policy so carefully = over many network nodes, such that the NN police would never be able to = find enough evidence for unfair tampering and hence that ISP would evade = NN policing. I think this is a strawman, as surely NN policing works by = measuring whether there is observable discrimination end to end, not by = having tech police swecure and scrutinize rputer/switch configurations. >=20 >> Terms like =E2=80=9Cthrottling=E2=80=9D are technically meaningless. = The lawgeneers who have written articles and books saying otherwise are = unconsciously incompetent at computer science. >=20 > There are use cases, both good and bad, for "throttling". It is and > has always been technically feasible to rate limit flows from anyone > to anyone. Advisable, sometimes! DDOS attacks are one case where > throttling is needed. [SM] Yes, and e.g. the EU rules allow for reasonable traffic = management, and during covid lock downs made it explicitly clear that in = some cases this can mean slowing down a whole class of traffic (lke = streaming video) as long as that is traffic management of the whole = class and not simply service X. So in reality many potential objections = against simplistic NN rules can be avoided simply by not making the NN = rules simplistic ;) >=20 > Breaking the user perception of being intentionally throttled vs the > fate of the the rest of the network would be a goodness. The side > effects of one service, living on a slow network, becoming suddenly > popular, is known as the "slashdot effect", and is mostly mediated by > leveraging CDN and cloud technologies, and totally out of the control > of the local ISP. [SM] In the short term for sure! Longer term an ISP constantly = running into such a problem might reconsider their connectivity with = upstream to remedy this issue or cooperation with that service provider = as long as these options are financially reasonable.... >=20 >>> We computer scientists call this viable alternative =E2=80=9Cend-to-en= d=E2=80=9D approach a =E2=80=9Cquality floor=E2=80=9D. >=20 > In googling I have thus far been unable to find a definition of > "Quality floor". Cite, please? [SM] Ah, good old quality_floor() which is a hand cfafted = artisanal version of the mass-produced floor() function used in many = programming languages ;) >=20 >> The good news is that we now have a practical means to measure it and = hard science to model it. >=20 > Weeds, here. >=20 >>> Maybe we should consciously and competently try it? >=20 > ... if only we had running code and rough consensus. [SM] I see what you did there... Tip of the hat Regards Sebastian >=20 >>=20 >>=20 >>=20 >> All the best, >>=20 >> Frank >>=20 >> Frantisek (Frank) Borsik >>=20 >>=20 >>=20 >> https://www.linkedin.com/in/frantisekborsik >>=20 >> Signal, Telegram, WhatsApp: +421919416714 >>=20 >> iMessage, mobile: +420775230885 >>=20 >> Skype: casioa5302ca >>=20 >> frantisek.borsik@gmail.com >>=20 >>=20 >>=20 >> On Sun, Oct 1, 2023 at 7:15=E2=80=AFPM Dave Taht via Nnagain = wrote: >>>=20 >>> 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). >>>=20 >>> 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] >>>=20 >>> I am basically planning to move the enormous discussion from over >>> here, titled "network neutrality back in the news": >>>=20 >>> = https://lists.bufferbloat.net/pipermail/starlink/2023-September/thread.htm= l >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> The third phase was when title ii was rescinded... and all that has >>> happened since. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> So here we "NN-again". Lay your issues out! >>>=20 >>>=20 >>>=20 >>> [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. >>>=20 >>> [2] https://archive.org/details/video1_20191129 >>> -- >>> 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 >=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