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 ABA2D3B29D for ; Mon, 2 Oct 2023 02:48:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1696229290; x=1696834090; i=moeller0@gmx.de; bh=vCnE3R7mI5B4QXuDM12MKHVO3Hb++ErTUrP/9z030q4=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=H9j0DcCLybvxfj7p7gVihY7TvAWb7IuzGBVNLh2uq/aZcI7n80xjX6KM5TSvASUiKDMP8o5bm4D eLoFA7K/F+bdaK5E4z8YsRcJOghkso8uV9NMzhud4boSA7ALH1dRH5yf5HjO5flnL4+QgCR77D2Jo K7WxFQSh505qWdMzMwEFkid7Hu/rFZeGB5ChbYInkIUf5+htn0mW6uPjW0HXXqKWCWZIVLQTVqjtn /Y7lVZabTl9NKa8cVeZCdyvDkfjvaXSGy6+LdkiHzsG9Ne6pbaVB4zt205JBSLEmi6GkusQf2YDoO LO53vJ1AooJBQm6Qwd/nf7Ywxnu4UKv0+NRw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([77.0.37.4]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MSKy8-1rBJAo2faS-00Sj35; Mon, 02 Oct 2023 08:48:10 +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:48:09 +0200 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:XPe5nEvu6FF9HELchKEQ9BqfRSJg6V5F6nmGNmutuTu6KoEnj2Z dfo6fXE6IUw6GKOQLsbzD/HD+dgSLkCWGkx+hp4eHgRyNrqDcmctTr5gDsxkgXlGzZ9TK6v K4487jkdLaraf84bEDAFUTUtB84g4oTxz7sY3Ma//aO5xCTBIXQRAY2vvF6LzB9yCjKjigg VAicQ/oUj0UZwaigsIlCw== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:stl8pr9+zNI=;MhQCpimnxW32OVfgrmoRYkkiBGi 0t+uGLnZEp57jjfZ+TWE7MG9uvNzcvSOwXZo6zEBFdp3pSb9joFa5ShdHrbNdDWuk9QsKQEjo 71R7LlIPHXPoQAh/4LO7MFKmiAUabnXqfVROgz9ejp2tE35p50MlzPMEdznVNXDsOXOQIZ5Vc /o00f+2qrepFIeoZAjqeJzp4So9eMJikXgvCUf9yv4rHsDFZMUFdJV4qS0PDuaQeQs4KjBRz4 LMhnNo4A6d9WhZHUjbdaH2GTXPoRYcKWELlz2Z446x08w8cSLX3n0TFmto6h4Emf76hYgiaqy Oi9Qu3dkGTr4rjMrC5Mn6WXYaHx4v6fJFXbDuWVhX6MypuH26ZuV3K3EZatiXBNmD+GWrnwjP HBnv6nkXN+/+XyNNvG57+z4B+U6+HK55X7Yrqi+gdCYi5JCRZNcczJVFwzFvfr9We+ri3lzgR t/jzo0jefHA/0emmd6EXYYrUYLxUHBBQJFd4euVeS/R0t9/7bDyQSFiDyVCw+XjgrsKfD3LJJ exfoyDUoMDceEsWSMY1q7O2EyZXSvuhn3Z/QRMccJodR7kTyWnt/Uuj2M95BSMFvEih9Ofr14 B3rXR3Cs82auGyy/+t8/Uj8SzsUbNsu8a5PJBcSGpsKn0HXpucsTx4BhRiotvMeoFftmZjVV6 W5hEslB0zm0MU4oxhoKP8/ON9Mq5VHB4k4RShDK7VBza8AyqXfNFWtjP0/tLFjCYA1272NaFD PDvgvnmSXzG+Fu+lq15eoBx2xowB8fUO4S/Vc4wfQXMFhUwsBFJqdbcXjZusrtAWGll2FKnyg vfA/jD+2XlmyJrk1eZhrCZWVrRA8CoRnlF2pK74tlojBMizZcMB1d3eXK/rp97+RRMZSdRvmA iPShAwd+plvySp/lzi5q9Ls4e+C6EvS+hU3NOULCScVn+DAxGz4l49jRm9+9JZX4l/FTuELev fstzhUMhbRfek96cHL6NpXd4oJM= 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:48:13 -0000 Hi Patrick, > On Oct 2, 2023, at 00:01, Patrick Maupin via Nnagain = wrote: >=20 > > =E2=80=9Cneutrality=E2=80=9D is framed by the experience of end = users >=20 > Assuming, arguendo, that's true, then the issue becomes one of = ensuring that bad actors can't slowly strangle the competition until = eventually the antitrust laws have to be invoked. >=20 > Because that's always too late. >=20 > Dave Taht and others have correctly pointed out that many of the = issues that have cropped up have purely technical solutions. [SM] Most of the technical reasons for observed (but not = intended) discrimination indeed seem to have technical solutions, ready = for deployment for roughly a decade now. But the business side of trying = to tilt the playing field for financial gains is not a technical problem = and hence has no specific technical solution (that offenders would be = willing to use); or rather the technical solution is "stop doing what = you di to create the artificial shortage" situation in the first place. = While we agree to call such actors, bad actors, before NN regulations = became effective such behavior was not in direct violation of the law = and regulations and hence seemed permitted. It is a "disease" of modern = large corporation to consider any behavior not explicitly forbidden to = be "fair game" (while at the same time lobbying hard to water down fail = all attempts at meaningful regulation), but I digress. >=20 > Maybe everything devolves to a technical issue? =20 [SM] I wish this was true, but alas at least in Europe there is = evidence for discrimination based on economic considerations, not = technical challenges. > I'm not sure, but it may be worthwhile to view current protocols, = norms, and regulations as a system that is under security threats from = bad actors*, and to enumerate some of the potential exploits and = consider potential mitigations. >=20 > Bearing in mind, of course, that one of the tools available to bad = actors may, in fact, be current or new regulations that impede the = self-help capabilities of ISPs and other ecosystem participants, but = also bearing in mind that the history of the internet as a whole = (replete with cooperative endeavors) is completely different from the = history of many of the rent-seeking businesses that are now aggressively = monetizing it. >=20 > In any case, it's easy these days to sit out negotiations between = Comcast and Netflix. Or Comcast and Disney over football, or whatever. = Because they're all big boys. [SM] It also has become clear that end-users can use VPNs to = essentially do poor-man's traffic engineering to route-around = accidentally or purposefully overloaded paths and encryption from = havning an ISP use DPI for uncouth purposes... > The holy grail is, as always, to guarantee that the _next_ netflix = can't be easily strangled in its crib. [SM] Without endorsing a single company here, I fully agree we = want the internet not to ossify and allow the continous emergence of new = things that might or might not gain usage based on their own features = and properties. Regards Sebastian >=20 > - Pat Maupin >=20 > [*] If there are no would-be bad actors, no regulation is needed. But = if there are would-be bad actors, then they will attempt to be = instrumental in shaping any new regulations, and many of the presumed = would-be bad actors have time, money, and histories of securing = significant face time with regulatory agencies such as the FCC. [SM] Technically or an act to be objectively bad it needs to = step over a clear "line in the sand", these used to be implicit and = shared by a community but now a days te only thing that works is = explicit rules and regulations that make clear was is and what is not = permitted, no? >=20 > On Sun, Oct 1, 2023 at 3:51=E2=80=AFPM Dave Cohen via Nnagain = wrote: > It=E2=80=99s useful for us to remember here that, politics aside, = =E2=80=9Cneutrality=E2=80=9D is framed by the experience of end users, = not by the experience of operators. While much of Martin=E2=80=99s = argument that malicious treatment and incapable design cannot often be = distinguished from one another is correct, I believe it to be beside the = point; from the perspective of most end users, =E2=80=9CI can=E2=80=99t = watch Netflix because Comcast is throttling it=E2=80=9D and =E2=80=9CI = can=E2=80=99t watch Netflix because Comcast doesn=E2=80=99t have enough = capacity where Netflix traffic ingresses=E2=80=9D may be distinguishable = arguments but they=E2=80=99re also equally egregious. (With apologies to = Jason, Comcast was my home ISP during that era of NN debates, so my = specific argument here is reflexive.) Most users will be sympathetic = enough to tolerate an occasional service hiccup but will not tolerate = repeated issues, regardless of the cause of those issues or their = personal ability to differentiate between those causes.=20 >=20 > Of course this is a two way street. Anyone inclined to believe that = large companies are going to conspiratorially behave maliciously took a = big giant victory lap when Cogent press released that they had = successfully throttled Netflix traffic in a controlled experiment, when = of course that commanded no such thing.=20 >=20 > I recall getting into a Twitter fight with Martin around this time on = that point. My argument was effectively that end user perception = wasn=E2=80=99t going to change and an ISP trying to nuance its way = through how it presents its traffic management (in effect, the = =E2=80=9CQuality Floor=E2=80=9D framework) was missing the point with = its customers; throwing more bandwidth at the problem was the only way = out. I=E2=80=99d like to think that time has proven my perspective = correct, although the growth in utilization of CDN and edge networking = topologies also subverted the need for bandwidth growth, at least over = the public Internet, to be quite so rapid.=20 >=20 > Dave Cohen > craetdave@gmail.com >=20 > > On Oct 1, 2023, at 3:52 PM, Dave Taht via Nnagain = wrote: > >=20 > > =EF=BB=BFI 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, 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. > >=20 > > 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. > >=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. > >=20 > > 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. > >=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. > >=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 > >=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. > >=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. > >=20 > >>> We computer scientists call this viable alternative = =E2=80=9Cend-to-end=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? > >=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. > >=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 > _______________________________________________ > Nnagain mailing list > Nnagain@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/nnagain > _______________________________________________ > Nnagain mailing list > Nnagain@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/nnagain