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 954D23B29D for ; Mon, 2 Oct 2023 03:28:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1696231681; x=1696836481; i=moeller0@gmx.de; bh=4HcmpZ9IKkrLe6sxuEV7+Li6NiXpIyQmgbwAhm8JFD0=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=lPgacYjGkB/kRhInOqVx5augUxfPFFgIuRJiUlVnD0Ba0CLMt60uX8QPeTVWjkJFgxrYub6uayX zOgMClB7k9F1oeex2J3fcxXsEqbvqEte3n3eXNqgKJu1vd0ovyyjxg9164r0WBtCfaivyPmckpNDl 0NP52Kv8bX850Cw2xK+xSdyfw5IJQZF9L01K9g6MKi3VfGzTsv1Jul4LFLNOBR5Ro2EP2fpDL7crY ul3zXV+TxJQdxfPzTfRJYaCPJTokojbyplqFDhDOIxvI5KyNy72OT4z5fFy1YLAxbZpaeAsMhP9p7 EOwrDhqQBek9eX7CPmpEYc9n7jPeVpnhmzeQ== 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 1M3DNt-1qmOw021jp-003g5b; Mon, 02 Oct 2023 09:28:01 +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 09:28:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <85FEF89F-966F-46D0-A957-84A07C51B2D0@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:eEYlGEZVFNu8pz0zkGAmbGvGLdtM3VirB8sIqbGokCn97NLqtwU Jtv82Du+YASNy1VGf15FlS1vCVPLW3hYZnu8CK06tIwe30qQaOFTel0GUS5N2FCWsO4R8tM 544a+ZXACyr569FiDEbtybFUax7pOZaxW5tvknw/a3zDY/WjU26xfo2W32nPv+GCVVyoR6u vuA3ZqZnLVhFIyIuht2Cg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:s6XCkLhRta8=;Ednfv9VEjD7u9VnZQhhJ0dy2SX1 R5j7xYt6nXdRw6SacLZdzDgIz+LbUt1GcoSjROsTaQAX2oXQon60nfv2zKKqk3xZiFHjD6KDN cRuqDzb0DFXcjlMPMYuS48LoW+ZhzSgAcbTnUXAr2DbHhlxOznSxQsizYusDQqYflgPE3Y3Jx 7vgAwmaLs6oVp9Xno1D6t94U1ITZg0uCHyqDtcytA9yS80JdSXmOel8UuXtinIn9ltfc1jGCD fb5fCZ29F8unOPZBbQb9ZMY9s19VkqNbZ1fEoWs7XH9TLegy8y+db9JywC9xBB5Lt7XmH0kLP cgC5lzi4rBWT0PecNF1qexfp4B0+fuHnnMux3HkCE8pjlS165xLP+m/cC3ex8dPMN8d67PNkw z3Y3jIsRgArpx2xtE6bajaySMRWGmNR0R/IL9CO/4G3k4nXgUQsAw33CPgT79qNxlHoTsLAnE NkBRXKeaPu24rDRCaeDFRPaFTxSAmM+LacoYz624hf52tPyBsU3L4iK6123DDm830rxOwsew3 Pb4MJ1HCYFRenGJM91Z2Ww8wwdCB/C/w91xUqihSqA0EfixWe+/TSLwyJI2pTJr+UEXiF65MJ wnEXtXKSvyzRnD5K8BnvaTRAAuOSyLix/cUoMhLuiRSwNCsdkJ5GAen+kfEEA2O7iYF04/pop Mhu5qiw7wsawC3IeYD2yysJwpGNts6rM/FRudnwBxVXxACmkdpxZATnfO+gZquiq9FCHmx00U d+8FRvsX+BoDk7yoxsxbGmcZSTiMKQ8JynKQ12JtVWpjkLpta64fSoyQb2pk7zEFAJUgkoSOT 6kHNQkdykc2Q3RcAzTMWc2CDj0Zk8XYYOD0WZAWx4RolLvB2hCiMC/uLFVjHPCfjmCvSRJKDQ LfaW2CLMKIA30L28vE8DZ5wfrGP/AXxadFFRsWbp3giGdBpDy6+oOBQsNboSrFb51q9dluAPV 3McWFhEQ5+zmpI5rHgyDwZsdHgs= 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 07:28:04 -0000 Hi Dan, > On Oct 2, 2023, at 03:34, dan via Nnagain = wrote: >=20 > I think a big problem with Net Neutrality is it's sort of a topic for = providers and not for end users. [SM] I respectfully disagree. If my ISP sells me access to the = internet, I expect being able to access the whole internet, at least as = far it is with the reasonable power of my ISP. So I would argue it is a = topic for both parties. > Most end users have no concept of what it is, why it's good or bad, = and if they have a compliant service or not. They confuse 'speed' with = packet loss and latency. [SM] I would agree that the majority of users might not have = actionable concepts of how the internet works, let alone what to expect = precisely, but I predict if we ask them whether they think it a good = idea for their ISP to pick winners and losers of content providers I = expect most of them to say no. > This is why my arguments are primarily from a consumer protection = perspective of forcing providers to be transparent in their NN or non-NN = activities. [SM] Transparency is indded an important factor, but IMHO not = sufficient. > If they are going to shape streaming video down, they should have to = put that in the big print on the plan. In doing this, customers would = get some practical information that doesn't rely on heavy technical = details and various opinions. Consumers will understand the 100x20 w/ = 1080p streams. This could be on the broadband nutrition label *but* I = would say you need to have that up-to-date for the times with key = information on there and with strikethrough text. ie, Download [ 100 ], = Upload [ 20 ], streaming [ 720 1080p 4k ] and that list can be updated = yearly during the BDC process or whatever. =20 [SM] Here we get into the weeds: a) for customers only having access to a single (broadband) ISP this = information would hardly be actionable b) personally I could agree to this, but e.g. Netflix [720], Amazon = [4K], GoogleTV [720] (or what ever google calls this service right now) = would IMHO be problematic. c) I think that this gets really hard to enforce unless the ISP also = throttled VPN/encrypted traffic and there I see a line crossed, no = amount of transparency would make it palatable if an ISP would heavily = throttle all encrypted traffic. >=20 > I'm really a proponent of creating a competitive environment, not = controlling the technical details of those products. [SM] +1; but that only ever helps in a competitive market = environment and that means there need to be enough buyers and sellers on = both sides that no single one gets an undue influence over the market. = At least in Germany we at best have an oligopoly market for internet = access, so the "free market" by itself does not solve the discrimination = problem. That might well be different in other parts of the world. > And making sure key parts of the rules require transparency, because = that can help drive competition. If a local competitor is running a = DPI's QoE box shaping down streaming, I think they should have to share = that conspicuously with the end user. I can then market directly = against that if I want. [SM] Again I fully endorse that, but feel that by itself would = not be enough. > I would say that I think that any government money should require NN = plans. If a company is taking government bribes for 100x20 speed, that = should be a NN 100x20. They can offer 100x20 w/ 1080p streaming also, = but that gov money should have NN baked into what they/we are paying = for. [SM] Interesting approach that I agree with, but again do not = think it to be enough. >=20 > I know that one of the initial ideas of NN was to say that there are = no fast lanes, but that's ridiculous because just having different speed = plans IS having fast lanes for premium pricing. [SM] I think this is a misunderstanding. NN is not against ISPs = offering different access capacity tiers at different prices, but that = within the transparent customer-known "capacity-limit" the ISP does not = pick winners or losers amount flows and especially not based on = financial considerations. If an ISPs sells internet access they better = do so, and they better not try to sell the same traffic a second time to = the content provider. So the fast lane "fast lane" argument really means = that the ISP does not built an unfair fast-lane for content provider A = (capA) over content provider B (capB), and even that is subtle, if cabA = puts caching nodes with the ISPs network, but capB does not a result in = accessibility is not "on the ISP" however if the ISP would additionally = slow down capB traffic that would be a problem. In a sense the thing = that is problematic is building fast-lanes by slowing down all the rest. > The only possible way around this is the allow or even enforce a = price per Mbps and make it like a utility which I don't think anyone = wants. Any other model eliminates the sane enforcement of a 'no fast = lanes' policy. =20 [SM] I think this is an attempt at reductio ad absurdum, that = does not really cover the NN position well enough to be useful here. = Think about it that wat, ISPs are not supposed to pick winners and = losers (or rather tilt the table to create winners and losers). > I believe that transparency is the key here. [SM] THe EU actually agrees., an impoertant part of the = NN-relevant EU regulation covers transparency. > Transparency in how bits are delivered and managed to the end user = allows the consumer to make choices without demanding unrealistic = education of those consumers. [SM] That however seems quite a challenge... though it is not = unheard of to offer multiple parallel explanations at different levels = of abstraction/complexity... > They know if they want more than 1080p streaming. They know if they = want a gamer or home work focused service that does that by shaping = streaming down to 1080p. There are consumer benefits to a non-NN = service. =20 [SM] Really only if the "unfairness" of that service are exactly = tailored to a specific users needs and desires, not sure that any single = such a policy would be desirable for the majority of end-users, but I = might be insufficiently creative here. > Those benefits dont outweigh the harm from secret shaping, but if all = of this is clearly shown in a conspicuous way like the broadband = nutrition label and there were teeth in that label, then NN is a feature = that can be advertised and DPI shaped is another feature that must be = advertised. [SM] The only way I see DPI shaping ever to be in the end-users = interesst is if that feature is under the end-users control. E.g. on a = very slow link the administrator might decide that interactive VCs are = more important than streaming video and might desire ways t achieve this = policy and might appreciate if the ISPs offers such de-prioritization as = a self-serve option > Now for my ISP version of this. [SM] And now it gets interesting ;) >=20 > I WANT to compete against the companies that have to put 1080p and no = 4k in their advertisements. I want to offer full NN packages for the = same price as their 'only 1080p' package. I want the competitive = environment and I want to know if the service area next to mine with = just 1 or 2 providers doesn't offer NN packages so I can move in on them = and offer them. =20 [SM] I wish all ISPs would have such a "bring it on" let's duke = it out on the merits attitude! Yest the big mass-market ISPs in my home = market do not really qualify for that all they compete about are nominal = "speed"/price (really capacity/price) and some additional features like = flat rate for telephony to fixed line and/or mobile networks. No details = given about specific properties... for these one needs to scour rge = internet fora to figure out what a specific ISPs customers mainly kvetch = about (and then one needs to abstract over the fact that not all = complaints are created equal and some say more about a user's deficiency = in expectation than about the ISP's service delivery). >=20 > So from my perspective, transparency in shaping is all I really think = should be done. And teeth in resolving a lie, ie false advertising, = with a rulebook already in place for that so no new legal theory needs = worked out. "I bought the 1G NN package and I'm running the NN test = suite and it says I'm shaped to 1080p video", rectify this ISP or I'm = going to throw a legal tantrum to FTC, FCC, and maybe my own lawyer and = get some penalty claims. And that test suite is pretty darn simple. = speed test, 1G. Netflix, 1080p. DPI shaped. [SM] Alas, that NN test suit is currently made of unobtainium. = Though some individual parts exist already. For example kudos to netflix = for fast.com, which as far as I understand uses essentially the same of = its CDN nodes for speedtests it would likely pick for content delivery = so these are pretty "realistic" testing conditions. Alas the other big = streaming platform have as far as I know not followed suit. As I tried to brain storm in a different context, what we would need at = the very least would be speedtests that houses its servers in at least = the networks of the big transit providers and runs comparative tests = against these (either all or random pairs selected for each test). And = while this would already be pretty ambitious to implement this would = only scratch the surface of what would be required. However one = redeeming fact is IMHO that NN-violations that achieve financial goals, = by necessity need to be perceivable by the eye-balls so the thing we are = looking for is likely not subtle but "in your face". >=20 > End rant. [SM] I rally wish more ISPs would have your spirit (and that we = had more ISPs competing for eye-balls)! Also I think that your stance = let the market settle this is conceptually in-line with our current = macroeconomic system and theory (I am just not sure whether yje internet = access market generally is healthy enough to relat on this mechanism to = sort out bad apples). Regards Sebastian >=20 > On Sun, Oct 1, 2023 at 4:01=E2=80=AFPM Patrick Maupin via Nnagain = wrote: > > =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. >=20 > 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. >=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. >=20 > The holy grail is, as always, to guarantee that the _next_ netflix = can't be easily strangled in its crib. >=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. >=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 > _______________________________________________ > Nnagain mailing list > Nnagain@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/nnagain