From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com [IPv6:2607:f8b0:4864:20::1129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8CECA3B29D for ; Sun, 1 Oct 2023 18:01:36 -0400 (EDT) Received: by mail-yw1-x1129.google.com with SMTP id 00721157ae682-5a2478862dbso23758657b3.2 for ; Sun, 01 Oct 2023 15:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696197696; x=1696802496; darn=lists.bufferbloat.net; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=WHqYGwhrZsnEDsPHWzsqz3I1pph9sgrgUxkislz9xas=; b=iIDPzwtCO//yXAZELsluuAUda+lEMi5tL/3wr0TVmAIvQhWGShRhsncsUNIz+rvKen VDMAwnpJ2DfHkAZpUvaoW/LB0Ey3pp2eeVICkiZdAGmompVlqxiSVsI4hM6sb7WoGfxH hI6u35n6sXoZ5A6g7z/EtX/mkhStiASEC+zSKLt+bLFVonf4Yk3DbLOic7RVdBUg41ki u+MHD5KGaA4AiUq7WOmEjOXKqV0t0qH3h8BvAzzOUCqr4m9KFfR6NDfBrw4efGofzArT C/U8hPYUDCd6uP57PAy6aVcaPOpIrgLHlLZXvo/lxMIjJrRiTesEvSTqOPuB7T/eHp51 QsrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696197696; x=1696802496; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WHqYGwhrZsnEDsPHWzsqz3I1pph9sgrgUxkislz9xas=; b=aA2VFDSht6tQVqif7TRf99z4grPzABYQbClpMdy+WWTq5GdeDJOGAXCMQElnlMHXen D7Z5Gj6dwFz+EGzMmMlFNkVPs3uAYEeIpWT7CFsMMcFqu6R/MCFlBPFwwpAJJBsKmuBL 0thmW4kVa1bnGTbCI3qD/bx3Rd1u6xugBZGfuNwVIwU9lx4JrkbyMlz191nN5pILtbMi vFKLwCbmV+mQPx4xQ6XHC0w5FVjgoKMumJetmI6Or7n62O6aVo5M+hL9nXLRFZdFCgCO loCovlZ9dpSVgOtNCm/4ludFmOXqIgKSIAds4qZ32GFVRxjcn9Bkp5trVxztz+l34jf1 GIuA== X-Gm-Message-State: AOJu0Yzux2yV7k1uA3oMHoWgvCjYtnQvD8BJNwZvAVXHaqrSnc1noPsS yS8NSXCYYGe/zJExAXDGpNcwEwv0y1NxSCp1deLJVr9vzO1VkA== X-Google-Smtp-Source: AGHT+IEI1jY8ncYeLoWDO9H8iK4Btgl4CbAH+PjLoWunnw9FmF9CGqo9et1sPfQXWZP/r0Ug++azRyhGmPgHPYIKTSo= X-Received: by 2002:a81:6502:0:b0:58d:7ec3:16c4 with SMTP id z2-20020a816502000000b0058d7ec316c4mr9836253ywb.34.1696197695049; Sun, 01 Oct 2023 15:01:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Patrick Maupin Date: Sun, 1 Oct 2023 17:01:23 -0500 Message-ID: To: =?UTF-8?Q?Network_Neutrality_is_back=21_Let=C2=B4s_make_the_technical_asp?= =?UTF-8?Q?ects_heard_this_time=21?= Content-Type: multipart/alternative; boundary="00000000000015132d0606aecddc" 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: Sun, 01 Oct 2023 22:01:36 -0000 --00000000000015132d0606aecddc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > =E2=80=9Cneutrality=E2=80=9D is framed by the experience of end users 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. Because that's always too late. Dave Taht and others have correctly pointed out that many of the issues that have cropped up have purely technical solutions. Maybe everything devolves to a technical issue? 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. 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. 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. The holy grail is, as always, to guarantee that the _next_ netflix can't be easily strangled in its crib. - Pat Maupin [*] 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. On Sun, Oct 1, 2023 at 3:51=E2=80=AFPM Dave Cohen via Nnagain < nnagain@lists.bufferbloat.net> 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 inca= pable > design cannot often be distinguished from one another is correct, I belie= ve > 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 ca= n=E2=80=99t watch Netflix > because Comcast doesn=E2=80=99t have enough capacity where Netflix traffi= c > ingresses=E2=80=9D may be distinguishable arguments but they=E2=80=99re a= lso 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 issue= s > or their personal ability to differentiate between those causes. > > Of course this is a two way street. Anyone inclined to believe that large > companies are going to conspiratorially behave maliciously took a big gia= nt > victory lap when Cogent press released that they had successfully throttl= ed > Netflix traffic in a controlled experiment, when of course that commanded > no such thing. > > I recall getting into a Twitter fight with Martin around this time on tha= t > point. My argument was effectively that end user perception wasn=E2=80=99= t 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 framew= ork) 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 persp= ective > correct, although the growth in utilization of CDN and edge networking > topologies also subverted the need for bandwidth growth, at least over th= e > public Internet, to be quite so rapid. > > Dave Cohen > craetdave@gmail.com > > > On Oct 1, 2023, at 3:52 PM, Dave Taht via Nnagain < > nnagain@lists.bufferbloat.net> wrote: > > > > =EF=BB=BFI kind of expect many, many forks of conversations here, and f= or those > > introducing a new topic, > > I would like to encourage using a relevant subject line, so I have > > changed this one to suit. > > > >> On Sun, Oct 1, 2023 at 11:57=E2=80=AFAM Frantisek Borsik > >> wrote: > >> > >> 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. > > > > 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! > > > >> Anyway, here is my bullet. I will argue with Martin, that - Net > Neutrality CAN'T be implemented: > > > > 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. > > > >> > >>> Whilst people argue over the virtues of net neutrality as a regulator= y > 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=9Cneutr= al=E2=80=9D regime for Internet > access. You like to access streaming media from a particular =E2=80=9Cove= r 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, in= cluding the one to > your preferred =E2=80=9Cover the top=E2=80=9D application, have been give= n a different > packet scheduling and routing treatment. > >>> It seems like an open-and-shut case of =E2=80=9Cthrottling=E2=80=9D r= esulting 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 nev= er survive the > resulting court case and expert witness scrutiny: > >> > >> > >> > https://www.martingeddes.com/one-reason-net-neutrality-cant-implemented/ > > > > 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. > > > > In part I kind of reject a few older arguments here in the face of > > subsequent, technical improvements on how the internet works. > > > > 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. > > > > 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. > > > > I believe something like this method lives on in Domos=C2=B4s work toda= y, > > 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. > > > > 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. > > > > 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. > > > > Instead: > > > > 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. > > > >> > >> I hope you will read the link ^^ before jumping to Martin's conclusion= , > but still, here it is: > >> > >>> > >>> So if not =E2=80=9Cneutrality=E2=80=9D, then what else? > > > > This is the phase where his arguments began to fall into the weeds. > > > >>> The only option is to focus on the end-to-end service quality. > > > > 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. > > > >>> The local traffic management is an irrelevance and complete > distraction. > > > > 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 > > > >> Terms like =E2=80=9Cthrottling=E2=80=9D are technically meaningless. T= he lawgeneers who > have written articles and books saying otherwise are unconsciously > incompetent at computer science. > > > > 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. > > > > 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. > > > >>> We computer scientists call this viable alternative =E2=80=9Cend-to-e= nd=E2=80=9D > approach a =E2=80=9Cquality floor=E2=80=9D. > > > > In googling I have thus far been unable to find a definition of > > "Quality floor". Cite, please? > > > >> The good news is that we now have a practical means to measure it and > hard science to model it. > > > > Weeds, here. > > > >>> Maybe we should consciously and competently try it? > > > > ... if only we had running code and rough consensus. > > > >> > >> > >> > >> All the best, > >> > >> Frank > >> > >> Frantisek (Frank) Borsik > >> > >> > >> > >> https://www.linkedin.com/in/frantisekborsik > >> > >> Signal, Telegram, WhatsApp: +421919416714 > >> > >> iMessage, mobile: +420775230885 > >> > >> Skype: casioa5302ca > >> > >> frantisek.borsik@gmail.com > >> > >> > >> > >>> On Sun, Oct 1, 2023 at 7:15=E2=80=AFPM Dave Taht via Nnagain < > nnagain@lists.bufferbloat.net> 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 an= d > >>> background, in the hope that one day, we can shed more light than hea= t > >>> about the science and technologies that "govern" the internet, to > >>> those that wish to regulate it. In the short term, I would like enoug= h > >>> 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.ht= ml > >>> > >>> 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 ow= n > >>> 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, an= d > >>> Jason Livinggood have weighed in on their stories on linkedin, > >>> twitter, and elsewhere. > >>> > >>> There was a second phase, somewhat triggered by netflix, that Jonatha= n > >>> Morton summarized in that thread, ending in the first establishment o= f > >>> 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 E= U > >>> 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-g= ive-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 > >>> -- > >>> 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 > > > > > > > > -- > > 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 > --00000000000015132d0606aecddc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> =E2=80=9Cneutrality=E2=80=9D is fram= ed by the experience of end users

Assu= ming, arguendo, that's true, then the issue becomes one of ensuring tha= t bad actors can't slowly strangle the competition until eventually the= antitrust laws have to be invoked.

Because that&#= 39;s always too late.

Dave Taht and others have co= rrectly pointed out that many of the issues that have cropped up have purel= y technical solutions.

Maybe everything devolves t= o a technical issue?=C2=A0 I'm not sure, but it may be worthwhile to vi= ew current protocols, norms, and regulations as a system that is under secu= rity threats from bad actors*, and to enumerate some of the potential explo= its and consider potential mitigations.

Bearin= g 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 th= e history of the internet as a whole (replete with cooperative endeavors) i= s completely different from the history of many of the rent-seeking busines= ses that are now aggressively monetizing it.

I= n any case, it's easy these days to sit out negotiations between Comcas= t and Netflix.=C2=A0 Or Comcast and Disney over football, or whatever.=C2= =A0 Because they're all big boys.

The holy gra= il is, as always, to guarantee that the _next_ netflix can't be easily = strangled in its crib.

=C2=A0- Pat Maupin

[*] If there are no would-be bad actors, no regulation= is needed.=C2=A0 But if there are would-be bad actors, then they will atte= mpt to be instrumental in shaping any new regulations, and many of the pres= umed would-be bad actors have time, money, and histories of securing signif= icant face time with regulatory agencies such as the FCC.
On = Sun, Oct 1, 2023 at 3:51=E2=80=AFPM Dave Cohen via Nnagain <nnagain@lists.bufferbloat.net> = wrote:
It=E2=80= =99s useful for us to remember here that, politics aside, =E2=80=9Cneutrali= ty=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 treat= ment 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 throt= tling it=E2=80=9D and =E2=80=9CI can=E2=80=99t watch Netflix because Comcas= t 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 eg= regious. (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.

Of course this is a two way street. Anyone inclined to believe that large c= ompanies 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.

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 fra= mework) was missing the point with its customers; throwing more bandwidth a= t 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 a= nd edge networking topologies also subverted the need for bandwidth growth,= at least over the public Internet, to be quite so rapid.

Dave Cohen
craetdave@gmail.co= m

> On Oct 1, 2023, at 3:52 PM, Dave Taht via Nnagain <nnagain@lists.bufferbloa= t.net> wrote:
>
> =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.
>
>> On Sun, Oct 1, 2023 at 11:57=E2=80=AFAM Frantisek Borsik
>> <frantisek.borsik@gmail.com> wrote:
>>
>> 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/o= r even stomach for current round of NN discussion.
>
> 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!
>
>> Anyway, here is my bullet. I will argue with Martin, that - Net Ne= utrality CAN'T be implemented:
>
> 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<= br> > arguing against what he described.
>
>>
>>> Whilst people argue over the virtues of net neutrality as a re= gulatory policy, computer science tells us regulatory implementation is a f= ool=E2=80=99s errand.
>>> Suppose for a moment that you are the victim of a wicked ISP t= hat engages in disallowed =E2=80=9Cthrottling=E2=80=9D under a =E2=80=9Cneu= tral=E2=80=9D regime for Internet access. You like to access streaming medi= a from a particular =E2=80=9Cover the top=E2=80=9D service provider. By coi= ncidence, the performance of your favoured application drops at the same ti= me your ISP launches a rival content service of its own.
>>> You then complain to the regulator, who investigates. She find= s that your ISP did indeed change their traffic management settings right a= t 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 applic= ation, 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 w= ill never survive the resulting court case and expert witness scrutiny:
>>
>>
>> https://www.marting= eddes.com/one-reason-net-neutrality-cant-implemented/
>
> 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<= br> > borders, saving an enormous amount on transit costs.=C2=A0 The rest of= the
> computing universe followed with enormous numbers of CDNs from the
> bigger services being built out in the years following.
>
> In part I kind of reject a few older arguments here in the face of
> subsequent, technical improvements on how the internet works.
>
> I had many discussions with martin back in the day. The reasoning in > this piece is pretty sound, except that "fairness" can be ac= hieved 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.
>
> My principal kvetch with his work was that every blog entry during
> this period making these points then ended up linking to a "Quali= ty
> 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.
>
> I believe something like this method lives on in Domos=C2=B4s work tod= ay,
> and despite them filing an internet draft on the subject (
> https://datatracker.ietf.org/doc/draft-ol= den-ippm-qoo/ ) I remain
> mostly in the dark, without being able to evaluate their methods
> against tools I already understand.
>
> I like the idea of what I think a "quality floor" might prov= ide, which
> is something that fq-everywhere can provide, and no known e2e
> congestion control can guarantee.
>
> I would like it if instead of ISPs selling "up to X bandwidth&quo= t; they
> sold a minimum guarantee of at least Y bandwidth, which is easier to > reason and provision for, but harder to sell.
>
> Instead:
>
> In the last 14 years I focused on restoring correct behavior of the > well-defined congestion controls of the internet, first documented
> here:=C2=A0 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.
>
>>
>> I hope you will read the link ^^ before jumping to Martin's co= nclusion, but still, here it is:
>>
>>>
>>> So if not =E2=80=9Cneutrality=E2=80=9D, then what else?
>
> This is the phase where his arguments began to fall into the weeds. >
>>> The only option is to focus on the end-to-end service quality.=
>
> I agree that achieving quality on various good metrics, especially
> under load, is needed. The popular MOS metric for voip could use some<= br> > improvement, and we lack any coherent framework for measuring
> videoconferencing well.
>
>>> The local traffic management is an irrelevance and complete di= straction.
>
> 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<= br> > 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 quali= ty"
> 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
>
>> Terms like =E2=80=9Cthrottling=E2=80=9D are technically meaningles= s. The lawgeneers who have written articles and books saying otherwise are = unconsciously incompetent at computer science.
>
> 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.
>
> 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 me= diated by
> leveraging CDN and cloud technologies, and totally out of the control<= br> > of the local ISP.
>
>>> We computer scientists call this viable alternative =E2=80=9Ce= nd-to-end=E2=80=9D approach a =E2=80=9Cquality floor=E2=80=9D.
>
> In googling I have thus far been unable to find a definition of
> "Quality floor". Cite, please?
>
>> The good news is that we now have a practical means to measure it = and hard science to model it.
>
> Weeds, here.
>
>>> Maybe we should consciously and competently try it?
>
> ... if only we had running code and rough consensus.
>
>>
>>
>>
>> All the best,
>>
>> Frank
>>
>> Frantisek (Frank) Borsik
>>
>>
>>
>> https://www.linkedin.com/in/frantisekborsik<= br> >>
>> Signal, Telegram, WhatsApp: +421919416714
>>
>> iMessage, mobile: +420775230885
>>
>> Skype: casioa5302ca
>>
>> fr= antisek.borsik@gmail.com
>>
>>
>>
>>> On Sun, Oct 1, 2023 at 7:15=E2=80=AFPM Dave Taht via Nnagain &= lt;nnaga= in@lists.bufferbloat.net> wrote:
>>>
>>> I am pleased to see over 100 people have signed up for this li= st
>>> already. I am not really planning on "activating" th= is list until
>>> tuesday or so, after a few more people I have reached out to s= ign up
>>> (or not).
>>>
>>> I would like y=C2=B4all to seek out people with differing opin= ions and
>>> background, in the hope that one day, we can shed more light t= han heat
>>> about the science and technologies that "govern" the= internet, to
>>> those that wish to regulate it. In the short term, I would lik= e enough
>>> of us to agree on an open letter, or NPRM filing,and to put ou= t 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 o= ver
>>> here, titled "network neutrality back in the news":<= br> >>>
>>> https://list= s.bufferbloat.net/pipermail/starlink/2023-September/thread.html
>>>
>>> to here. I expect that we are going to be doing this discussio= n for a
>>> long time, and many more issues besides my short term ones wil= l 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 start= ed 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 G= ettys, 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 establis= hment of
>>> some title ii rules in 2015.
>>>
>>> The third phase was when title ii was rescinded... and all tha= t has
>>> happened since.
>>>
>>> I, for one, am fiercely proud about how our tech community ros= e to
>>> meet the challenge of covid, and how, for example, videoconfer= encing
>>> mostly just worked for so many, after a postage stamp sized st= art in
>>> 2012[2]. The oh-too-faint-praise for that magnificent effort f= rom
>>> higher levels rankles me greatly, but I will try to get it und= er
>>> control.
>>>
>>> And this fourth phase, opening in a few weeks, is more, I thin= k about
>>> privacy and power than all the other phases, and harmonization= with EU
>>> legislation, perhaps. What is on the table for the industry an= d
>>> 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-give-fcc-a-plan-to-secure-wi-fi-routers.html<= br> >>> In this case this is not so much a fight, I hope, but a collab= orative
>>> effort towards a better, faster, lower latency, and more secur= e,
>>> internet for everyone.
>>>
>>> [2] https://archive.org/details/video1_20191= 129
>>> --
>>> Oct 30: https://net= devconf.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/nn= again
>
>
>
> --
> Oct 30: https://netdevconf.= info/0x17/news/the-maestro-and-the-music-bof.html
> Dave T=C3=A4ht CSO, LibreQos
> _______________________________________________
> Nnagain mailing list
> Nna= gain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
_______________________________________________
Nnagain mailing list
Nnagain@= lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/nnagain
--00000000000015132d0606aecddc--