From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 69D513B2A4; Sat, 30 Sep 2023 17:57:17 -0400 (EDT) Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-2774f6943b1so8794265a91.0; Sat, 30 Sep 2023 14:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696111036; x=1696715836; darn=lists.bufferbloat.net; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=vB/NHDuiHR7zSdrK3UQDzGSIyyyqKLe7pBjZS4vFDgc=; b=VnwyQ8kVHeL1fgmw5/Iw31IhG5u855EEgQ0x5AkNGKJOxpjQgvI9Y8naNa57KrI35u bcshqWAxwnDDYemsA5g1gPvDQjUT5sOyANCJcgC+XcOznN4q+wgIV6LfUA+GYICHMB2m 4O1DzOVaSD3iNIA1pkzCrQ6iIaklF4z9bPo0Af0ExM5qLMzpc8X6p/kxXmhOpxqXnTbg Xd2DH5NSWhWiZpqs3q9zt3zC36FUMcX35AQ3pXbkX1M5dyov7+JRF4IrpgqhQVT26FB9 hEB6H5l9vzKCH2Gf+pojOmN9SQMI0FQISZNRTQFQzQkOquzgej/AmQTEeSpJje/uFm2e tSnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696111036; x=1696715836; h=content-transfer-encoding:cc: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=vB/NHDuiHR7zSdrK3UQDzGSIyyyqKLe7pBjZS4vFDgc=; b=QwGjUHqo9l2ySBccCPMW7SfPcLQ2SDleI22F0jnUaYh9jXTYYxG5ZuE7W0r4H758yE aND0tRVSHwtOZQJgLzfzxc0da65SwWedtIXNXV7E8yeRGgb+JmU+Gq5fuLsDXkWhI5tV oW7CfLASmDAeEIyvSmm3LPlO90raUg0lQ0XNg4NijR/201e5tC6FqZbAGtItZDXY6xKQ Ex7i+HB1P8k/cg5Z6VVRx4IQ/xlWniusbqbNWUCKm5lOgxf+TsoGecHR9oekaeCE32H/ h96pFXbt7tr51c1sdJjfmLg2C21ssy0oMJDgDwTuDFYrweDJ53wLW4zA8BQce81JjSyI D6MA== X-Gm-Message-State: AOJu0Yxa1H62O7KDZch46vtwLHO1bmLCvXQDYGhOVCQADiENITD6mG3t Y6pGxH88A32P184JuTtAWMP/Ql3FPwRH8WSce/Q= X-Google-Smtp-Source: AGHT+IEB3H5F0x6gWHsCVuWfHG+KNQKMoUS6eoyvp1d56kyflPHbG/stQ5ATcVmCH5tIpa4jAB8NW0GWg2rbCQu9rCQ= X-Received: by 2002:a17:90b:1d04:b0:269:85d:2aef with SMTP id on4-20020a17090b1d0400b00269085d2aefmr7359454pjb.20.1696111036040; Sat, 30 Sep 2023 14:57:16 -0700 (PDT) MIME-Version: 1.0 References: <5so3r00n-31pn-14s7-7775-08731s3s551r@ynat.uz> <7508FE73-A154-4CBA-984C-748A80C5FFEC@gmail.com> <039490DA-48A7-4AE2-B00F-AA2A260FB747@gmail.com> <3F6D16C8-530E-4066-8B6A-C0644B3C2D2C@gmx.de> <4129491C-FFC7-4E5E-A5A4-8CBE9B5C5255@gmx.de> In-Reply-To: From: Dave Taht Date: Sat, 30 Sep 2023 14:57:04 -0700 Message-ID: To: Sebastian Moeller Cc: Mike Conlow , Rpm , bloat , Dave Taht via Starlink Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [Starlink] New email list: NNagain for network neutrality X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2023 21:57:17 -0000 I have created a new mailing list to discuss title ii and nn regulation, and called it NNagain, partially because Ronald Reagan=C2=B4s old phrase "There you go again", transliterated, has been an earworm in my head for a week now. (this is not a + or - for title ii and nn, it=C2=B4s just my earworm! now, possibly yours) I just issued everyone an invite to join. While I suspect that many users of my mailing lists are interested in this broad topic, I felt that continuing to flood so many mailboxes with it to be a bit much, and it is going to drag on for a long time. I am interested in the broadest possible and *civil* discussion with members of all internet-using professions. It would be nice if we had a resident regulatory lawyer or three, from all over the world, we had people building or managing networks, and those making software, government folk, NGOs, name the speciality! all in the loop. I imagine others will establish slack channels, or matrix, or mastodon, and so forth, but in my mind, email remains the bedrock of complex communications. I for one would like to really go in deep on some complex regulations, and also into the history of what worked, and what didn=C2=B4t, reflect on a future in space, and internet expansion throughout the world, debunk claims made by all sides, and try to come up with a blueprint for a future internet better for everyone. Somehow. Please pass out the invite also especially to folk with a different perspective or skillset you can *enjoy* constructively disagreeing with - and possibly mutual enlightenment will happen! The list url is: https://lists.bufferbloat.net/listinfo/nnagain Thank you all for being such a great crowd to hang with. On Sat, Sep 30, 2023 at 10:35=E2=80=AFAM Dave Taht wr= ote: > > Despite the sturm und drang here if you google for network neutrality > there was a lot of press coverage 4 days ago. > > ... and mostly, silence, on the twitters at least. How is mastodon or > other social media? > > I couldn=C2=B4t help but notice that this was essentially, Diane > Feinstein=C2=B4s last press release (she died yesterday): > > https://www.feinstein.senate.gov/public/index.cfm/press-releases?id=3DC6F= FF484-16F1-4CC9-9836-F36446C3B33D > > > On Sat, Sep 30, 2023 at 8:23=E2=80=AFAM Dave Taht w= rote: > > > > The starlink list was not originally cc=C2=B4d and yet since I think th= is > > debate concerns that also, I have added the cc back. Carry on! > > > > On Sat, Sep 30, 2023 at 8:20=E2=80=AFAM Sebastian Moeller via LibreQoS > > wrote: > > > > > > Hi Mike, > > > > > > [I took the liberty to remove some individual address from the Cc, as= I assume most/all already be covered by the lists] > > > > > > > > > > On Sep 30, 2023, at 16:41, Mike Conlow wro= te: > > > > > > > > First, a thank you to Dave, and lots of you all, for longtime sheph= erding of this community and efforts to make the Internet better. > > > > > > > > As I read this thread and think about the coming debate in the U.S.= , two things come to mind: > > > > > > > > 1. Ofcom is considering a net neutrality "clarification". The first= topic in the consultation is whether ISPs should be allowed to offer "prem= ium quality retail plans". It doesn't specify the technical implementation,= but there would be different plans for "users who mainly stream" vs "peopl= e who use high quality virtual reality applications". Apparently ISPs feel = the existing NN rules are not clear on whether this is allowed. > > > > > > [SM] Not sure this is not simply an attempt of using regulato= ry divergence from the EU (IMHO for no good reason or outcome)... Also und = er the existing EU rules ISPs are arguably already free to treat the whole = class of latency sensitive VR to lower delay than bulk streaming as long as= they do son consistently and not based on commercial relationships with th= e senders... > > > During the covid19 lock downs the EU offered clarification on the reg= ulation that really drove home the do not discriminate inside of a specific= traffic class, and define classes by purely technical not economical param= eters. That said, I always like to look at data and hence am happy to the t= he UK apparently prepping to run that experiment (I am also happy not to li= ve there right now not having to prticipate in said experiment*). > > > > > > > > > *) Other than that the british islands offer a lot of really great pl= aces I certainly would like to live at, but I digress. > > > > > > > > > > > The question I'm thinking about is do we want an Internet where end= user plans are divided up this way? > > > > > > [SM] Personally, I consider internet access infrastructure an= d do not think this looks like a good way forward. > > > > > > > And if not, is a NN regulation the right place to put those rules? > > > > > > [SM] Could well be, but depends on the framing, no? > > > > > > > > > > > 2. To the point in the PS of the below email, I would agree things = are mostly working in the EU, and in the US. But things are broken in Germa= ny to the point where consumers have a degraded Internet experience because= their ISP won't provision enough interconnection. > > > > > > [SM] This a very peculiar case of the local incumbent Deutsch= e Telekom (DTAG) (all in all a pretty competent ISP that runs a tight ship = in its network and tends to follow regulations to the letter (not however n= ecessarily to the intent, but they are not different from other corporation= s of similar size)). DTAG is large enough to qualify as tier 1 (T1) ISP tha= t is, to the best of our knowledge they do not pay anybody for transit and = peer with all other T1-ISPs, they also have a relative large share of eye-b= alls in one of Europes larger and profitable markets. They (as did AT&T and= Verizon in the US and probably other ISPs in similar positions as well) th= at most of their users traffic was within network (e.g. from German compani= es hosted/homed by DTAG) or via important partners like Google that have de= cent peering links (unclear whether/if Google actually is charged for that)= but that there is a considerable number of services that reach DTAG eye-ba= lls via their transit, that is essentially via one of the other T1-ISPs (I = simplify here, I have no insight in the actual bisiness relationships betwe= en all players). And now DTAG basically instructed its generally capable ne= twork team to simply manage the size of the peering links with the big tran= sit-providers carefully so that they never fully clogg, but clearly see inc= reased packet loss and queueing delay during prime time. That in turn is cl= early a competition problem if streaming service A judders/jitters/and buff= ers jumps between quality tiers while streaming service B smoothly and bori= ngly just streams at the desired resolution. Now Telekom is happy to offer = service A a product they call "internet transit" but that is priced pretty = high (I have seen some comparative numbers for transit pricing in Germany I= am not permitted to share or reveal more about) so high in fact that no co= ntent provider that can afford more than a single transit provider would us= e for anything but reaching DTAG eye-balls or closely related ones (like in= the past SwissCom). > > > This behaviour is not s secret but evades regulatory action, because = it does not openly violate the EU regulation which in the BEREC interpretat= ion does not really cover the interconnection side. DTAG is careful enough = to not purposefully target specific potential customers but simply treats a= ll traffic coming in/out via "other transit than its own" as "has to tolera= te overheated links during primetime". > > > > > > > > > > Are NN rules the right place to address this > > > > > > [SM] They could well be the actual text of the 2015/2120 does= not make a distinction between access and interconnection. But this is a t= ricky field and will directly affect parts of larger ISP's core business so= I do not see this happen in the EU anytime soon, unless ISPs like Telekom = clearly abuses this in a way that is too obvious... ATM it is mostly teleco= m, but I believe any of the big old monopoly incumbents likely is big enoug= h in its home market to pull of a stunt like this, so there is the potentia= l of someone over doing it... > > > > > > > and make sure it doesn't happen in the US? Or is one bad actor acro= ss the EU and US the cost of doing business and the Internet ecosystem and = "market" are mostly solving the issue? > > > > > > [SM] As happy as I am to diss DTAG for that behavior (I am al= so happy to praise it in ears where it shows exemplary behavior) DTAG is no= t alone in that business acumen, I think that some of the big US telco's do= d/do exactly the same, but unlike telekom I have no evidence. > > > > > > > > > Regards > > > Sebastian > > > > > > P.S.: I was a customer at DTAG for several years and I did not notice= the conscious under-peering with the other T1 ISPs in my day to day usage,= so while the issue clearly and measurably exists it is not an issue that n= ormal users will encounter often and are also unlikely to properly root-cau= se (the blame will likely land by my example service A above). > > > > > > > > > > > > > > > > > > > > > > On Sat, Sep 30, 2023 at 8:19=E2=80=AFAM Sebastian Moeller via Rpm <= rpm@lists.bufferbloat.net> wrote: > > > > Hi Frantisek, > > > > > > > > > On Sep 30, 2023, at 14:00, Frantisek Borsik via Rpm wrote: > > > > > > > > > > Back then in 2015, when NN was enacted by Wheeler & CO, there was= a great body of work (IMHO) done on this subject by Martin Geddes: > > > > > https://www.martingeddes.com/1261-2/ > > > > > > > > > > But let's pick one report written by his colleagues and published= by Ofcom (UK telecoms regulator): > > > > > > > > > > =E2=80=A2 You cannot conflate =E2=80=98equality of [packet]= treatment=E2=80=99 with delivering equality of [user application] outcomes= . Only the latter matters, as ordinary users don=E2=80=99t care what happen= ed to the packets in transit. Yet the relevant academic literature fixates = on the local operation of the mechanisms (including Traffic Management), no= t their global aggregate effect. > > > > > > > > [SM] The EU laid out pretty clear why they mandated the NN = regulations in eu regulation 2015/2120: > > > > > > > > [...] > > > > (8) > > > > When providing internet access services, providers of those service= s should treat all traffic equally, without discrimination, restriction or = interference, independently of its sender or receiver, content, application= or service, or terminal equipment. According to general principles of Unio= n law and settled case-law, comparable situations should not be treated dif= ferently and different situations should not be treated in the same way unl= ess such treatment is objectively justified. > > > > (9) > > > > The objective of reasonable traffic management is to contribute to = an efficient use of network resources and to an optimisation of overall tra= nsmission quality responding to the objectively different technical quality= of service requirements of specific categories of traffic, and thus of the= content, applications and services transmitted. Reasonable traffic managem= ent measures applied by providers of internet access services should be tra= nsparent, non-discriminatory and proportionate, and should not be based on = commercial considerations. The requirement for traffic management measures = to be non-discriminatory does not preclude providers of internet access ser= vices from implementing, in order to optimise the overall transmission qual= ity, traffic management measures which differentiate between objectively di= fferent categories of traffic. Any such differentiation should, in order to= optimise overall quality and user experience, be permitted only on the bas= is of objectively different technical quality of service requirements (for = example, in terms of latency, jitter, packet loss, and bandwidth) of the sp= ecific categories of traffic, and not on the basis of commercial considerat= ions. Such differentiating measures should be proportionate in relation to = the purpose of overall quality optimisation and should treat equivalent tra= ffic equally. Such measures should not be maintained for longer than necess= ary. > > > > (10) > > > > Reasonable traffic management does not require techniques which mon= itor the specific content of data traffic transmitted via the internet acce= ss service. > > > > (11) > > > > Any traffic management practices which go beyond such reasonable tr= affic management measures, by blocking, slowing down, altering, restricting= , interfering with, degrading or discriminating between specific content, a= pplications or services, or specific categories of content, applications or= services, should be prohibited, subject to the justified and defined excep= tions laid down in this Regulation. Those exceptions should be subject to s= trict interpretation and to proportionality requirements. Specific content,= applications and services, as well as specific categories thereof, should = be protected because of the negative impact on end-user choice and innovati= on of blocking, or of other restrictive measures not falling within the jus= tified exceptions. Rules against altering content, applications or services= refer to a modification of the content of the communication, but do not ba= n non-discriminatory data compression techniques which reduce the size of a= data file without any modification of the content. Such compression enable= s a more efficient use of scarce resources and serves the end-users=E2=80= =99 interests by reducing data volumes, increasing speed and enhancing the = experience of using the content, applications or services concerned. > > > > (12) > > > > Traffic management measures that go beyond such reasonable traffic = management measures may only be applied as necessary and for as long as nec= essary to comply with the three justified exceptions laid down in this Regu= lation. > > > > [...] > > > > > > > > There really is little IMHO that can be brought against these, all = pretty fair and reasonable. What it does is accept that internet access is = essential infrastructure and that hence access needs to be as well regulate= d as access to water, electricity, gas, streets, ... . Yes this has some co= nsequences of what ISPs can and can not do. But this is normal "cost of bus= iness". I for one am quite happy about this regulation existing as locally = it did away with some (not all) shenanigans of some ISPs that were clearly = not operating in the interest of their paying eye-balls. > > > > > > > > There is a whole cottage industry of consultants that decry the EU'= s decision and try to lobby against it, but honestly reading these mostly m= akes me think harsher regulation might be required (on consultans about how= much they are allowed to massage the facts ;) ). > > > > > > > > Regards > > > > Sebastian > > > > > > > > P.S.: Of course if we look close enough we surely can find corner-c= ases where either the EU regulations or the translation into national law r= esult in less desirable outcomes, but "nothing is perfect" and all in all t= he regulations seem to be "good enough". With the caveat that explicitly ex= cluding ISP interconnect from the regulations BEREC essentially pointed the= way for ISPs wanting to monetize their eye-balls twice to do so via interc= onnects, but that only works for the 800 pound gorillas and generally is no= t a game smaller ISPs can play. I do understand why BEREC wants to stay out= of the interconnection issue, as this is rather complicated and the market= seems to generally work okay-ish (that is not badly enough to make interve= ntion a hot-button issue for voters and hence politicians). > > > > > > > > > > > > > > > > > > > > > > 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 Fri, Sep 29, 2023 at 6:15=E2=80=AFPM dan via Rpm wrote: > > > > > ok, lots and lots of great comments here for sure. > > > > > > > > > > bandwidth abundance: Not for most people and ISPs. The 'carrier= s' aren't carrying to many places at affordable rates. I've pulled quotes = from Lumen and Zayo at over $5k/month/gig. We typically pay 900-1400 for a= gig of service. This isn't abundance and it's widespread and it leaves on= ly major providers that can afford/amortize out 100G transits etc. > > > > > My answer to this is one that Dave and I have bounced back and fo= rth is the idea of micro IXs in every municipality and having that somehow = tied into access to the ROW in counties etc. Not fully hashed out, but the= fiber is in the ground, it could be sold, but the carriers are not well in= centivised to sell it. It takes the better part of a year to get a DIA wit= hin 100ft of a Lumen hut sometimes... Heck, it could even be a government = program to get an =CE=BCIX with x feet of every school, city hall, and libr= ary. I don't care how it's done but this would get abundance NEAR end user= s and open up essentially every town to competition. > > > > > > > > > > monopoly. This is a historical thing for most cable and DSL incu= mbents. They have enjoyed virtual monopolies with cable owning population = centers and DSL owning the outskirts and there is no product darwinism here= where customer satisfaction is a pressure. That may not be the future but= it definitely is the past. These companies may have to shift into custome= r satisfaction as a major part instead of a minor part of their corporate c= ulture to fend off fttx and ultra-modern wisps. > > > > > > > > > > Starlink is not offering significant competition to major carrier= s. Starlink's 1.5 million customers are at LEAST 90% pulled from other s= atellite services and small ISPs. Spectrum and Comcast's losses to starlin= k are measured in decimal points. > > > > > > > > > > Only fttx and ultra-modern wireless tech really threatens these i= ncumbents. Typical wisps aren't putting a dent in these guys, just scrapin= g the paint off their bumper. We're pulling customers at the scale of 'doz= ens' for example. Spectrum's management doesn't know we exist we're such a= small threat to them. > > > > > > > > > > But to further the point here, these fttx and ultra-modern wisps = can only exist in places where there is adequate carrier services to start = with. In areas where they spend the money and do the build but there aren'= t good carrier services, those fiber services suck and the wISPs start to c= law back even with inferior technology. We've pulled quite a few customers= off fttx deployments because of this sort of situation. > > > > > > > > > > > > > > > On Fri, Sep 29, 2023 at 7:28=E2=80=AFAM Rich Brown wrote: > > > > > Thank you Jonathan for this clear description of the issues and t= heir history. I wonder if there's a fourth one - privacy. > > > > > > > > > > Rosenworcel's talk https://docs.fcc.gov/public/attachments/DOC-39= 7257A1.pdf also points out that ISPs might want to monetize our traffic pat= terns and location data. (This is less of an issue in the EU, but the US re= mains a Wild West in this regard.) > > > > > > > > > > I am hopeful that the FCC will include this in their NPRM (which = must be available by now but I haven't looked...) > > > > > > > > > > - Rich Brown > > > > > > > > > > > On Sep 29, 2023, at 12:54 AM, Jonathan Morton via Rpm wrote: > > > > > > > > > > > >> On 29 Sep, 2023, at 1:19 am, David Lang via Bloat wrote: > > > > > >> > > > > > >> Dave T called out earlier that the rise of bittorrent was a la= rge part of the inital NN discussion here in the US. But a second large por= tion was a money grab from ISPs thinking that they could hold up large paid= websites (netflix for example) for additional fees by threatening to make = their service less useful to their users (viewing their users as an asset t= o be marketed to the websites rather than customers to be satisfied by prov= iding them access to the websites) > > > > > >> > > > > > >> I don't know if a new round of "it's not fair that Netflix doe= sn't pay us for the bandwidth to service them" would fall flat at this poin= t or not. > > > > > > > > > > > > I think there were three more-or-less separate concerns which h= ave, over time, fallen under the same umbrella: > > > > > > > > > > > > > > > > > > 1: Capacity-seeking flows tend to interfere with latency-sensi= tive flows, and the "induced demand" phenomenon means that increases in lin= k rate do not in themselves solve this problem, even though they may be sol= d as doing so. > > > > > > > > > > > > This is directly addressed by properly-sized buffers and/or AQM= , and even better by FQ and SQM. It's a solved problem, so long as the sol= utions are deployed. It's not usually necessary, for example, to specifica= lly enhance service for latency-sensitive traffic, if FQ does a sufficientl= y good job. An increased link rate *does* enhance service quality for both= latency-sensitive and capacity-seeking traffic, provided FQ is in use. > > > > > > > > > > > > > > > > > > 2: Swarm traffic tends to drown out conventional traffic, due = to congestion control algorithms which try to be more-or-less fair on a per= -flow basis, and the substantially larger number of parallel flows used by = swarm traffic. This also caused subscribers using swarm traffic to impair = the service of subscribers who had nothing to do with it. > > > > > > > > > > > > FQ on a per-flow basis (see problem 1) actually amplifies this = effect, and I think it was occasionally used as an argument for *not* deplo= ying FQ. ISPs' initial response was to outright block swarm traffic where = they could identify it, which was then softened to merely throttling it hea= vily, before NN regulations intervened. Usage quotas also showed up around= this time, and were probably related to this problem. > > > > > > > > > > > > This has since been addressed by several means. ISPs may use F= Q on a per-subscriber basis to prevent one subscriber's heavy traffic from = degrading service for another. Swarm applications nowadays tend to employ = altruistic congestion control which deliberately compensates for the large = number of flows, and/or mark them with one or more of the Least Effort clas= s DSCPs. Hence, swarm applications are no longer as damaging to service qu= ality as they used to be. Usage quotas, however, still remain in use as a = profit centre, to the point where an "unlimited" service is a rare and prec= ious specimen in many jurisdictions. > > > > > > > > > > > > > > > > > > 3: ISPs merged with media distribution companies, creating a c= onflict of interest in which the media side of the business wanted the inte= rnet side to actively favour "their own" media traffic at the expense of "t= he competition". Some ISPs began to actively degrade Netflix traffic, in p= articular by refusing to provision adequate peering capacity at the nodes t= hrough which Netflix traffic predominated, or by zero-rating (for the purpo= se of usage quotas) traffic from their own media empire while refusing to d= o the same for Netflix traffic. > > > > > > > > > > > > **THIS** was the true core of Net Neutrality. NN regulations f= orced ISPs to carry Netflix traffic with reasonable levels of service, even= though they didn't want to for purely selfish and greedy commercial reason= s. NN succeeded in curbing an anti-competitive and consumer-hostile practi= ce, which I am perfectly sure would resume just as soon as NN regulations w= ere repealed. > > > > > > > > > > > > And this type of practice is just the sort of thing that techno= logies like L4S are designed to support. The ISPs behind L4S actively do n= ot want a technology that works end-to-end over the general Internet. They= want something that can provide a domination service within their own wall= ed gardens. That's why L4S is a NN hazard, and why they actively resisted = all attempts to displace it with SCE. > > > > > > > > > > > > > > > > > > All of the above were made more difficult to solve by the monop= olistic nature of the Internet service industry. It is actively difficult = for Internet users to move to a truly different service, especially one bas= ed on a different link technology. When attempts are made to increase comp= etition, for example by deploying a publicly-funded network, the incumbents= actively sabotage those attempts by any means they can. Monopolies are in= herently customer-hostile, and arguments based on market forces fail in the= ir presence. > > > > > > > > > > > > - Jonathan Morton > > > > > > > > > > > > _______________________________________________ > > > > > > Rpm mailing list > > > > > > Rpm@lists.bufferbloat.net > > > > > > https://lists.bufferbloat.net/listinfo/rpm > > > > > > > > > > _______________________________________________ > > > > > Rpm mailing list > > > > > Rpm@lists.bufferbloat.net > > > > > https://lists.bufferbloat.net/listinfo/rpm > > > > > _______________________________________________ > > > > > Rpm mailing list > > > > > Rpm@lists.bufferbloat.net > > > > > https://lists.bufferbloat.net/listinfo/rpm > > > > > > > > _______________________________________________ > > > > Rpm mailing list > > > > Rpm@lists.bufferbloat.net > > > > https://lists.bufferbloat.net/listinfo/rpm > > > > > > _______________________________________________ > > > LibreQoS mailing list > > > LibreQoS@lists.bufferbloat.net > > > https://lists.bufferbloat.net/listinfo/libreqos > > > > > > > > -- > > Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof= .html > > Dave T=C3=A4ht CSO, LibreQos > > > > -- > Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.h= tml > Dave T=C3=A4ht CSO, LibreQos --=20 Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.htm= l Dave T=C3=A4ht CSO, LibreQos