From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 CE4333CB39 for ; Sat, 30 Sep 2023 08:43:22 -0400 (EDT) Received: by mail-pg1-x533.google.com with SMTP id 41be03b00d2f7-577fff1cae6so1153858a12.1 for ; Sat, 30 Sep 2023 05:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1696077802; x=1696682602; darn=lists.bufferbloat.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=b3f4AIUbUM5GT7XAC4Y7bAdWwu+RufoQPUU29WYgg54=; b=equQM1Bxo1rZXqu1WCeLTCo76kU1eI2sDqk2kl7wSYQjquRcm8EB22xIeBb8I8PiO6 UeD/8CrRQrF2Fn/CB5MxY2cIYc7qQFZKtk43noDWiBOOo19ehmagoeGdpbfhJLaSkufO H90myEOxhluWvDqzDY0ikSJUfQ6TFO4DBoRCc/Jz9dYYBCvr7bTcnsjMCCCmc/Ar/QnT 7gUbscb9Q+wIHqLHrsdpcR7YYjxARQp6iNVVnTTmRAyI/Yqm6sJeemPvw+j+HhozGe37 jZejgIG56M6n0WNkXwvkux602pQrlxQG1tO1Qnog+E3Aty8Pqv3dtj2TWsBAcmq2tFR+ Rpqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696077802; x=1696682602; h=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=b3f4AIUbUM5GT7XAC4Y7bAdWwu+RufoQPUU29WYgg54=; b=SQHmpDMShBl7C9cOsB0cqQCdA2+lLdNQCBbOiA026CyCDMZIbz8awtG6u4qNXBD+Nz AidZ1S+3by42Pgr9vw2vdzgJBBhU+qetFECz2FfLVWuwnVxHMsvJquclT+2+qNiY2ksD MMdAhCCleYwT00aG4mh8iJ91R/G0OL3cHBEKlmGy0ZmsESnpFqaeX0r9A42dC9xCg8LP BUInAA7/ufzK1Vfl3TOflr0c17s3BZ7x2z+OF9G/Mwj0Lh9eAllZCYHwhDOosBNqxcbd BA3I8Kk0+yY7zLWChErPKqoCvawQ9bQe5J55nVhpKLjDupNe3K4ExnTo/pKB3fw3v5Lg 6AmA== X-Gm-Message-State: AOJu0YxywGYqthheUuTFzSfRbdB36ixnGabMOaGLxdn2YayUrMcCyTuA DHSXkSqog/VyOq1mL/oVkuWSQZuJmulz4e6mO5K0Zg== X-Google-Smtp-Source: AGHT+IHt07V4FeETXHi3RU5+t4J+5/6RoNXCu4s+k+hZZkDA674tqvtFT1xuy0xxP080yJ9QHRsO1udNJom8V1YRVAs= X-Received: by 2002:a17:90b:3654:b0:26f:6f2a:a11 with SMTP id nh20-20020a17090b365400b0026f6f2a0a11mr10968813pjb.12.1696077801334; Sat, 30 Sep 2023 05:43:21 -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> In-Reply-To: <3F6D16C8-530E-4066-8B6A-C0644B3C2D2C@gmx.de> From: Vint Cerf Date: Sat, 30 Sep 2023 13:42:59 +0100 Message-ID: To: Sebastian Moeller Cc: Frantisek Borsik , Dave Taht via Starlink , dan , libreqos , Jamal Hadi Salim , Rpm , bloat Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000e77461060692e29c" Subject: Re: [Rpm] [Starlink] [Bloat] [LibreQoS] net neutrality back in the news X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2023 12:43:23 -0000 --000000000000e77461060692e29c Content-Type: multipart/alternative; boundary="000000000000dcbcbf060692e2ad" --000000000000dcbcbf060692e2ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable the phrase "treat equally" can (maybe should?) be interpreted as offering the same options for traffic handling to all parties on the same terms and conditions. If there is only one class of service, then equally is the only option. If there are multiple classes of service, then these could (should?) be available to all customers indiscriminately. For example, there might be several distinct services with different maximum bit rates; the higher rates possibly available for a higher charge. If there is discrimination, it should be on the basis of customer choice and not dictated by the provider. Is that consistent with the European interpretation? v On Sat, Sep 30, 2023 at 1:19=E2=80=AFPM Sebastian Moeller via Starlink < starlink@lists.bufferbloat.net> wrote: > Hi Frantisek, > > > On Sep 30, 2023, at 14:00, Frantisek Borsik via Rpm < > rpm@lists.bufferbloat.net> 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] treat= ment=E2=80=99 with > delivering equality of [user application] outcomes. Only the latter > matters, as ordinary users don=E2=80=99t care what happened to the packet= s in > transit. Yet the relevant academic literature fixates on the local > operation of the mechanisms (including Traffic Management), not 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 services > should treat all traffic equally, without discrimination, restriction or > interference, independently of its sender or receiver, content, applicati= on > or service, or terminal equipment. According to general principles of Uni= on > law and settled case-law, comparable situations should not be treated > differently and different situations should not be treated in the same wa= y > unless 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 > transmission quality responding to the objectively different technical > quality of service requirements of specific categories of traffic, and th= us > of the content, applications and services transmitted. Reasonable traffic > management measures applied by providers of internet access services shou= ld > be transparent, non-discriminatory and proportionate, and should not be > based on commercial considerations. The requirement for traffic managemen= t > measures to be non-discriminatory does not preclude providers of internet > access services from implementing, in order to optimise the overall > transmission quality, traffic management measures which differentiate > between objectively different categories of traffic. Any such > differentiation should, in order to optimise overall quality and user > experience, be permitted only on the basis of objectively different > technical quality of service requirements (for example, in terms of > latency, jitter, packet loss, and bandwidth) of the specific categories o= f > traffic, and not on the basis of commercial considerations. Such > differentiating measures should be proportionate in relation to the purpo= se > of overall quality optimisation and should treat equivalent traffic > equally. Such measures should not be maintained for longer than necessary= . > (10) > Reasonable traffic management does not require techniques which monitor > the specific content of data traffic transmitted via the internet access > service. > (11) > Any traffic management practices which go beyond such reasonable traffic > management measures, by blocking, slowing down, altering, restricting, > interfering with, degrading or discriminating between specific content, > applications or services, or specific categories of content, applications > or services, should be prohibited, subject to the justified and defined > exceptions laid down in this Regulation. Those exceptions should be subje= ct > to strict interpretation and to proportionality requirements. Specific > content, applications and services, as well as specific categories thereo= f, > should be protected because of the negative impact on end-user choice and > innovation of blocking, or of other restrictive measures not falling with= in > the justified exceptions. Rules against altering content, applications or > services refer to a modification of the content of the communication, but > do not ban non-discriminatory data compression techniques which reduce th= e > size of a data file without any modification of the content. Such > compression enables a more efficient use of scarce resources and serves t= he > end-users=E2=80=99 interests by reducing data volumes, increasing speed a= nd > 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 > necessary to comply with the three justified exceptions laid down in this > Regulation. > [...] > > 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 > regulated as access to water, electricity, gas, streets, ... . Yes this h= as > some consequences of what ISPs can and can not do. But this is normal "co= st > of business". I for one am quite happy about this regulation existing as > locally it did away with some (not all) shenanigans of some ISPs that wer= e > 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 > makes 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-cases > where either the EU regulations or the translation into national law resu= lt > in less desirable outcomes, but "nothing is perfect" and all in all the > regulations seem to be "good enough". With the caveat that explicitly > excluding ISP interconnect from the regulations BEREC essentially pointed > the way for ISPs wanting to monetize their eye-balls twice to do so via > interconnects, but that only works for the 800 pound gorillas and general= ly > is not 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 intervention 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 <+421%20919%20416%20714> > > > > iMessage, mobile: +420775230885 <+420%20775%20230%20885> > > > > 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 'carriers' > 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 > only major providers that can afford/amortize out 100G transits etc. > > My answer to this is one that Dave and I have bounced back and forth 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 > incentivised to sell it. It takes the better part of a year to get a DIA > within 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 h= all, > and library. I don't care how it's done but this would get abundance NEA= R > end users and open up essentially every town to competition. > > > > monopoly. This is a historical thing for most cable and DSL > incumbents. 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 b= e > the future but it definitely is the past. These companies may have to > shift into customer satisfaction as a major part instead of a minor part = of > their corporate culture to fend off fttx and ultra-modern wisps. > > > > Starlink is not offering significant competition to major carriers. > Starlink's 1.5 million customers are at LEAST 90% pulled from other > satellite services and small ISPs. Spectrum and Comcast's losses to > starlink are measured in decimal points. > > > > Only fttx and ultra-modern wireless tech really threatens these > incumbents. Typical wisps aren't putting a dent in these guys, just > scraping the paint off their bumper. We're pulling customers at the scal= e > of 'dozens' 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 sta= rt > to claw 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 their > history. I wonder if there's a fourth one - privacy. > > > > Rosenworcel's talk > https://docs.fcc.gov/public/attachments/DOC-397257A1.pdf also points out > that ISPs might want to monetize our traffic patterns and location data. > (This is less of an issue in the EU, but the US remains a Wild West in th= is > regard.) > > > > I am hopeful that the FCC will include this in their NPRM (which must b= e > available by now but I haven't looked...) > > > > - Rich Brown > > > > > On Sep 29, 2023, at 12:54 AM, Jonathan Morton via Rpm < > rpm@lists.bufferbloat.net> wrote: > > > > > >> On 29 Sep, 2023, at 1:19 am, David Lang via Bloat < > bloat@lists.bufferbloat.net> wrote: > > >> > > >> Dave T called out earlier that the rise of bittorrent was a large > part of the inital NN discussion here in the US. But a second large porti= on > 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 > to be marketed to the websites rather than customers to be satisfied by > providing them access to the websites) > > >> > > >> I don't know if a new round of "it's not fair that Netflix doesn't > pay us for the bandwidth to service them" would fall flat at this point o= r > not. > > > > > > I think there were three more-or-less separate concerns which have, > over time, fallen under the same umbrella: > > > > > > > > > 1: Capacity-seeking flows tend to interfere with latency-sensitive > flows, and the "induced demand" phenomenon means that increases in link > 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 solutio= ns > are deployed. It's not usually necessary, for example, to specifically > enhance service for latency-sensitive traffic, if FQ does a sufficiently > 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 use= d > 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* deploying > FQ. ISPs' initial response was to outright block swarm traffic where the= y > could identify it, which was then softened to merely throttling it heavil= y, > before NN regulations intervened. Usage quotas also showed up around thi= s > time, and were probably related to this problem. > > > > > > This has since been addressed by several means. ISPs may use FQ on a > per-subscriber basis to prevent one subscriber's heavy traffic from > degrading service for another. Swarm applications nowadays tend to emplo= y > altruistic congestion control which deliberately compensates for the larg= e > number of flows, and/or mark them with one or more of the Least Effort > class DSCPs. Hence, swarm applications are no longer as damaging to > service quality 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 ra= re > and precious specimen in many jurisdictions. > > > > > > > > > 3: ISPs merged with media distribution companies, creating a conflic= t > of interest in which the media side of the business wanted the internet > side to actively favour "their own" media traffic at the expense of "the > competition". Some ISPs began to actively degrade Netflix traffic, in > particular by refusing to provision adequate peering capacity at the node= s > through which Netflix traffic predominated, or by zero-rating (for the > purpose of usage quotas) traffic from their own media empire while refusi= ng > to do the same for Netflix traffic. > > > > > > **THIS** was the true core of Net Neutrality. NN regulations forced > ISPs to carry Netflix traffic with reasonable levels of service, even > though they didn't want to for purely selfish and greedy commercial > reasons. NN succeeded in curbing an anti-competitive and consumer-hostil= e > practice, which I am perfectly sure would resume just as soon as NN > regulations were repealed. > > > > > > And this type of practice is just the sort of thing that technologies > like L4S are designed to support. The ISPs behind L4S actively do not wa= nt > a technology that works end-to-end over the general Internet. They want > something that can provide a domination service within their own walled > gardens. That's why L4S is a NN hazard, and why they actively resisted a= ll > attempts to displace it with SCE. > > > > > > > > > All of the above were made more difficult to solve by the monopolisti= c > nature of the Internet service industry. It is actively difficult for > Internet users to move to a truly different service, especially one based > on a different link technology. When attempts are made to increase > competition, for example by deploying a publicly-funded network, the > incumbents actively sabotage those attempts by any means they can. > Monopolies are inherently customer-hostile, and arguments based on market > forces fail in their 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 > > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > --=20 Please send any postal/overnight deliveries to: Vint Cerf Google, LLC 1900 Reston Metro Plaza, 16th Floor Reston, VA 20190 +1 (571) 213 1346 until further notice --000000000000dcbcbf060692e2ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
the phrase "treat equally" can (maybe should?) b= e interpreted as offering the same options for traffic handling to all part= ies on the same terms and conditions. If there is only one class of service= , then equally is the only option. If there are multiple classes of service= , then these could (should?) be available to all customers indiscriminately= . For example, there might be several distinct services with different maxi= mum bit rates; the higher rates possibly available for a higher charge. If = there is discrimination, it should be on the basis of customer choice and n= ot dictated by the provider.=C2=A0

Is that consisten= t with the European interpretation?

v

On Sat, Sep 30, 2023 at 1:19=E2=80=AFPM Sebastian Moeller via Starl= ink <starlink@lists.bu= fferbloat.net> wrote:
Hi Frantisek,

> On Sep 30, 2023, at 14:00, Frantisek Borsik via Rpm <rpm@lists.bufferbloat.net<= /a>> 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):
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 You cannot conflate =E2=80=98equal= ity of [packet] treatment=E2=80=99 with delivering equality of [user applic= ation] outcomes. Only the latter matters, as ordinary users don=E2=80=99t c= are what happened to the packets in transit. Yet the relevant academic lite= rature fixates on the local operation of the mechanisms (including Traffic = Management), not their global aggregate effect.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 [SM] The EU laid out pretty clear why they mand= ated the NN regulations in eu regulation 2015/2120:

[...]
(8)
When providing internet access services, providers of those services should= treat all traffic equally, without discrimination, restriction or interfer= ence, independently of its sender or receiver, content, application or serv= ice, or terminal equipment. According to general principles of Union law an= d settled case-law, comparable situations should not be treated differently= and different situations should not be treated in the same way unless such= treatment is objectively justified.
(9)
The objective of reasonable traffic management is to contribute to an effic= ient use of network resources and to an optimisation of overall transmissio= n quality responding to the objectively different technical quality of serv= ice requirements of specific categories of traffic, and thus of the content= , applications and services transmitted. Reasonable traffic management meas= ures applied by providers of internet access services should be transparent= , non-discriminatory and proportionate, and should not be based on commerci= al considerations. The requirement for traffic management measures to be no= n-discriminatory does not preclude providers of internet access services fr= om implementing, in order to optimise the overall transmission quality, tra= ffic management measures which differentiate between objectively different = categories of traffic. Any such differentiation should, in order to optimis= e overall quality and user experience, be permitted only on the basis of ob= jectively different technical quality of service requirements (for example,= in terms of latency, jitter, packet loss, and bandwidth) of the specific c= ategories of traffic, and not on the basis of commercial considerations. Su= ch differentiating measures should be proportionate in relation to the purp= ose of overall quality optimisation and should treat equivalent traffic equ= ally. Such measures should not be maintained for longer than necessary.
(10)
Reasonable traffic management does not require techniques which monitor the= specific content of data traffic transmitted via the internet access servi= ce.
(11)
Any traffic management practices which go beyond such reasonable traffic ma= nagement measures, by blocking, slowing down, altering, restricting, interf= ering with, degrading or discriminating between specific content, applicati= ons or services, or specific categories of content, applications or service= s, should be prohibited, subject to the justified and defined exceptions la= id down in this Regulation. Those exceptions should be subject to strict in= terpretation and to proportionality requirements. Specific content, applica= tions and services, as well as specific categories thereof, should be prote= cted because of the negative impact on end-user choice and innovation of bl= ocking, or of other restrictive measures not falling within the justified e= xceptions. Rules against altering content, applications or services refer t= o a modification of the content of the communication, but do not ban non-di= scriminatory data compression techniques which reduce the size of a data fi= le without any modification of the content. Such compression enables a more= efficient use of scarce resources and serves the end-users=E2=80=99 intere= sts 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 manageme= nt measures may only be applied as necessary and for as long as necessary t= o comply with the three justified exceptions laid down in this Regulation.<= br> [...]

There really is little IMHO that can be brought against these, all pretty f= air and reasonable. What it does is accept that internet access is essentia= l infrastructure and that hence access needs to be as well regulated as acc= ess to water, electricity, gas, streets, ... . Yes this has some consequenc= es of what ISPs can and can not do. But this is normal "cost of busine= ss". I for one am quite happy about this regulation existing as locall= y it did away with some (not all) shenanigans of some ISPs that were clearl= y not operating in the interest of their paying eye-balls.

There is a whole cottage industry of consultants that decry the EU's de= cision and try to lobby against it, but honestly reading these mostly makes= me think harsher regulation might be required (on consultans about how muc= h they are allowed to massage the facts ;) ).

Regards
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sebastian

P.S.: Of course if we look close enough we surely can find corner-cases whe= re either the EU regulations or the translation into national law result in= less desirable outcomes, but "nothing is perfect" and all in all= the regulations seem to be "good enough". With the caveat that e= xplicitly excluding ISP interconnect from the regulations BEREC essentially= pointed the way for ISPs wanting to monetize their eye-balls twice to do s= o via interconnects, but that only works for the 800 pound gorillas and gen= erally is not a game smaller ISPs can play. I do understand why BEREC wants= to stay out of the interconnection issue, as this is rather complicated an= d the market seems to generally work okay-ish (that is not badly enough to = make intervention a hot-button issue for voters and hence politicians).



>
> All the best,
>
> Frank
>
> Frantisek (Frank) Borsik
>
>=C2=A0
>
> https://www.linkedin.com/in/frantisekborsik
>
> Signal, Telegram, WhatsApp: +421919416714
>
> iMessage, mobile: +420775230885
>
> Skype: casioa5302ca
>
> franti= sek.borsik@gmail.com
>
>
>
> On Fri, Sep 29, 2023 at 6:15=E2=80=AFPM dan via Rpm <rpm@lists.bufferbloat.net<= /a>> wrote:
> ok, lots and lots of great comments here for sure.=C2=A0
>
> bandwidth abundance:=C2=A0 Not for most people and ISPs.=C2=A0 The = 9;carriers' aren't carrying to many places at affordable rates.=C2= =A0 I've pulled quotes from Lumen and Zayo at over $5k/month/gig.=C2=A0= We typically pay 900-1400 for a gig of service.=C2=A0 This isn't abund= ance and it's widespread and it leaves only major providers that can af= ford/amortize out 100G transits etc.
> My answer to this is one that Dave and I have bounced back and forth i= s the idea of micro IXs in every municipality and having that somehow tied = into access to the ROW in counties etc.=C2=A0 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.=C2=A0 It takes the better part of a year to get a DI= A within 100ft of a Lumen hut sometimes...=C2=A0 Heck, it could even be a g= overnment program to get an =CE=BCIX with x feet of every school, city hall= , and library.=C2=A0 I don't care how it's done but this would get = abundance NEAR end users and open up essentially every town to competition.=
>
> monopoly.=C2=A0 This is a historical thing for most cable and DSL incu= mbents.=C2=A0 They have enjoyed virtual monopolies with cable owning popula= tion centers and DSL owning the outskirts and there is no product darwinism= here where customer satisfaction is a pressure.=C2=A0 That may not be the = future but it definitely is the past.=C2=A0 These companies may have to shi= ft into customer satisfaction as a major part instead of a minor part of th= eir corporate culture to fend off fttx and ultra-modern wisps.
>
> Starlink is not offering significant competition to major carriers.=C2= =A0 =C2=A0 Starlink's 1.5 million customers are at LEAST 90% pulled fro= m other satellite services and small ISPs.=C2=A0 Spectrum and Comcast's= losses to starlink are measured in decimal points.
>
> Only fttx and ultra-modern wireless tech really threatens these incumb= ents.=C2=A0 Typical wisps aren't putting a dent in these guys, just scr= aping the paint off their bumper.=C2=A0 We're pulling customers at the = scale of 'dozens' for example.=C2=A0 Spectrum's management does= n't know we exist we're such a small threat to them.=C2=A0 =C2=A0 >
> But to further the point here, these fttx and ultra-modern wisps can o= nly exist in places where there is adequate carrier services to start with.= =C2=A0 In areas where they spend the money and do the build but there aren&= #39;t good carrier services, those fiber services suck and the wISPs start = to claw back even with inferior technology.=C2=A0 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 <richb.hanover@gmail.com&g= t; wrote:
> Thank you Jonathan for this clear description of the issues and their = history. I wonder if there's a fourth one - privacy.
>
> Rosenworcel's talk https://docs.fcc= .gov/public/attachments/DOC-397257A1.pdf also points out that ISPs migh= t want to monetize our traffic patterns and location data. (This is less of= an issue in the EU, but the US remains 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 <rpm@lists.bufferblo= at.net> wrote:
> >
> >> On 29 Sep, 2023, at 1:19 am, David Lang via Bloat <bloat@lists.buffe= rbloat.net> wrote:
> >>
> >> Dave T called out earlier that the rise of bittorrent was a l= arge part of the inital NN discussion here in the US. But a second large po= rtion was a money grab from ISPs thinking that they could hold up large pai= d websites (netflix for example) for additional fees by threatening to make= their service less useful to their users (viewing their users as an asset = to be marketed to the websites rather than customers to be satisfied by pro= viding them access to the websites)
> >>
> >> I don't know if a new round of "it's not fair th= at Netflix doesn't pay us for the bandwidth to service them" would= fall flat at this point or not.
> >
> > I think there were three more-or-less separate concerns which hav= e, over time, fallen under the same umbrella:
> >
> >
> > 1:=C2=A0 Capacity-seeking flows tend to interfere with latency-se= nsitive flows, and the "induced demand" phenomenon means that inc= reases in link rate do not in themselves solve this problem, even though th= ey may be sold as doing so.
> >
> > This is directly addressed by properly-sized buffers and/or AQM, = and even better by FQ and SQM.=C2=A0 It's a solved problem, so long as = the solutions are deployed.=C2=A0 It's not usually necessary, for examp= le, to specifically enhance service for latency-sensitive traffic, if FQ do= es a sufficiently good job.=C2=A0 An increased link rate *does* enhance ser= vice quality for both latency-sensitive and capacity-seeking traffic, provi= ded FQ is in use.
> >
> >
> > 2:=C2=A0 Swarm traffic tends to drown out conventional traffic, d= ue 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.=C2=A0 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 ef= fect, and I think it was occasionally used as an argument for *not* deployi= ng FQ.=C2=A0 ISPs' initial response was to outright block swarm traffic= where they could identify it, which was then softened to merely throttling= it heavily, before NN regulations intervened.=C2=A0 Usage quotas also show= ed up around this time, and were probably related to this problem.
> >
> > This has since been addressed by several means.=C2=A0 ISPs may us= e FQ on a per-subscriber basis to prevent one subscriber's heavy traffi= c from degrading service for another.=C2=A0 Swarm applications nowadays ten= d to employ altruistic congestion control which deliberately compensates fo= r the large number of flows, and/or mark them with one or more of the Least= Effort class DSCPs.=C2=A0 Hence, swarm applications are no longer as damag= ing to service quality as they used to be.=C2=A0 Usage quotas, however, sti= ll remain in use as a profit centre, to the point where an "unlimited&= quot; service is a rare and precious specimen in many jurisdictions.
> >
> >
> > 3:=C2=A0 ISPs merged with media distribution companies, creating = a conflict of interest in which the media side of the business wanted the i= nternet side to actively favour "their own" media traffic at the = expense of "the competition".=C2=A0 Some ISPs began to actively d= egrade Netflix traffic, in particular by refusing to provision adequate pee= ring capacity at the nodes through which Netflix traffic predominated, or b= y zero-rating (for the purpose of usage quotas) traffic from their own medi= a empire while refusing to do the same for Netflix traffic.
> >
> > **THIS** was the true core of Net Neutrality.=C2=A0 NN regulation= s forced ISPs to carry Netflix traffic with reasonable levels of service, e= ven though they didn't want to for purely selfish and greedy commercial= reasons.=C2=A0 NN succeeded in curbing an anti-competitive and consumer-ho= stile practice, which I am perfectly sure would resume just as soon as NN r= egulations were repealed.
> >
> > And this type of practice is just the sort of thing that technolo= gies like L4S are designed to support.=C2=A0 The ISPs behind L4S actively d= o not want a technology that works end-to-end over the general Internet.=C2= =A0 They want something that can provide a domination service within their = own walled gardens.=C2=A0 That's why L4S is a NN hazard, and why they a= ctively resisted all attempts to displace it with SCE.
> >
> >
> > All of the above were made more difficult to solve by the monopol= istic nature of the Internet service industry.=C2=A0 It is actively difficu= lt for Internet users to move to a truly different service, especially one = based on a different link technology.=C2=A0 When attempts are made to incre= ase competition, for example by deploying a publicly-funded network, the in= cumbents actively sabotage those attempts by any means they can.=C2=A0 Mono= polies are inherently customer-hostile, and arguments based on market force= s fail in their presence.
> >
> > - Jonathan Morton
> >
> > _______________________________________________
> > Rpm mailing list
> > Rp= m@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/rpm >
> _______________________________________________
> Rpm mailing list
> Rpm@lis= ts.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm
> _______________________________________________
> Rpm mailing list
> Rpm@lis= ts.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm

_______________________________________________
Starlink mailing list
Starlin= k@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink


--
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, = 16th Floor
Reston, VA 20190
+1 (571) 213 1346
=


unti= l further notice



--000000000000dcbcbf060692e2ad-- --000000000000e77461060692e29c Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPlwYJKoZIhvcNAQcCoIIPiDCCD4QCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggzxMIIEtjCCA56gAwIBAgIQeAMYYHb81ngUVR0WyMTzqzANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA3MjgwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFz IFIzIFNNSU1FIENBIDIwMjAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvLe9xPU9W dpiHLAvX7kFnaFZPuJLey7LYaMO8P/xSngB9IN73mVc7YiLov12Fekdtn5kL8PjmDBEvTYmWsuQS 6VBo3vdlqqXZ0M9eMkjcKqijrmDRleudEoPDzTumwQ18VB/3I+vbN039HIaRQ5x+NHGiPHVfk6Rx c6KAbYceyeqqfuJEcq23vhTdium/Bf5hHqYUhuJwnBQ+dAUcFndUKMJrth6lHeoifkbw2bv81zxJ I9cvIy516+oUekqiSFGfzAqByv41OrgLV4fLGCDH3yRh1tj7EtV3l2TngqtrDLUs5R+sWIItPa/4 AJXB1Q3nGNl2tNjVpcSn0uJ7aFPbAgMBAAGjggGKMIIBhjAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHzM CmjXouseLHIb0c1dlW+N+/JjMB8GA1UdIwQYMBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MHsGCCsG AQUFBwEBBG8wbTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3Ry MzA7BggrBgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvcm9vdC1y My5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIz LmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEANyYcO+9JZYyqQt41 TMwvFWAw3vLoLOQIfIn48/yea/ekOcParTb0mbhsvVSZ6sGn+txYAZb33wIb1f4wK4xQ7+RUYBfI TuTPL7olF9hDpojC2F6Eu8nuEf1XD9qNI8zFd4kfjg4rb+AME0L81WaCL/WhP2kDCnRU4jm6TryB CHhZqtxkIvXGPGHjwJJazJBnX5NayIce4fGuUEJ7HkuCthVZ3Rws0UyHSAXesT/0tXATND4mNr1X El6adiSQy619ybVERnRi5aDe1PTwE+qNiotEEaeujz1a/+yYaaTY+k+qJcVxi7tbyQ0hi0UB3myM A/z2HmGEwO8hx7hDjKmKbDCCA18wggJHoAMCAQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUA MEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWdu MRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEg MB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzAR BgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4 Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuu l9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJ pij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh 6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti +w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEA S0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9u bG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaM ld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88 q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/f hO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBNAwggO4oAMCAQICEAG/h5ZiH7Y4815iq/th nt8wDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gQXRsYXMgUjMgU01JTUUgQ0EgMjAyMDAeFw0yMzA3MjMx MzIwNDRaFw0yNDAxMTkxMzIwNDRaMCAxHjAcBgkqhkiG9w0BCQEWD3ZpbnRAZ29vZ2xlLmNvbTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALt6lfq1Df5y+axmhOcln+xEroS9ECyvXulr 0YJrYUFAfZWcMF4wHKBIaiJoRgigoH54oj0ZJONAwwHu5MsSbQOzA4xG9z7sQS2+COjdBbO3r6ZL XiFIejuawlzgjqbYPGHNjEvrtrTWYRIT/JJVQiQb4ydYYunqRYitbRQ7LmKgd0eEwHukcYdy9vko nlwMMCFxkOxzCnu118NIfFEEigR8+Iga1HX5cE6hiyCoE5GGC7vyQnNj7wYoKHZkan4yqTos+xir 1RZ4kS4q6gtOD5unmxmP0+Mq01txSBmRTJA/V/KAx1XW6Gff9woDrtQ4R5on/SHelnUotVKnznwL xLkCAwEAAaOCAdAwggHMMBoGA1UdEQQTMBGBD3ZpbnRAZ29vZ2xlLmNvbTAOBgNVHQ8BAf8EBAMC BaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQrocHqVFFn5Qu8tf6r SIxBQtZIbTBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3 dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAMBgNVHRMBAf8EAjAAMIGaBggrBgEFBQcBAQSB jTCBijA+BggrBgEFBQcwAYYyaHR0cDovL29jc3AuZ2xvYmFsc2lnbi5jb20vY2EvZ3NhdGxhc3Iz c21pbWVjYTIwMjAwSAYIKwYBBQUHMAKGPGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2Fj ZXJ0L2dzYXRsYXNyM3NtaW1lY2EyMDIwLmNydDAfBgNVHSMEGDAWgBR8zApo16LrHixyG9HNXZVv jfvyYzBGBgNVHR8EPzA9MDugOaA3hjVodHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzYXRs YXNyM3NtaW1lY2EyMDIwLmNybDANBgkqhkiG9w0BAQsFAAOCAQEAUbN/EBRBmbSQuzm5OOKc6wiX tZO+O3+f8oGtpWESn5tLpBnxMB90r+2PoMMREKPrK2JvNJeEaLs4cSbB7GPrhnY6t3UoXq2Z37Wj oKAQUDTbvkf2bTKtwbjukQ07Hm/DLbjWi3PvjmCLfqGWiJbOSk2AhMIgm8LtIpZG2MxRKZ2lDBDS CUN44mnyUBKh219itnfcYBbpm4xTV5tcMBtdy/eyWtVkQF4SqUXVpA8ZxTYi79AmUxm6+vdMmfTa 4B4uRAmHf5CTXxTxFeWa9h3DGWzWXptgT1QS1SeDKU/ylauO1iWxy8t9si4pRsyWdAGneHgATocU 7tew5FshRKvVpDGCAmowggJmAgEBMGgwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gQXRsYXMgUjMgU01JTUUgQ0EgMjAyMAIQAb+H lmIftjjzXmKr+2Ge3zANBglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQg15Hu6HoyQbBX FN4dV311KendN0E6qMcppij7RSYaitAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMjMwOTMwMTI0MzIyWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglg hkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0B AQcwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAG+DpfurpgPEQ4DmKOed6ouPqI77g3oB NLM7L9GMh/qGAbhGMNwxSWndYQm+LprxAR/cMLGjcVVB+h/b9a8bxjDJWYNJ9bMtS6DZRIyxKDSz ZlqcX+y3+JGnSEp9jt/Yzw8VEghVGrbsQ+XXcrl4Fk1DciBLfdILHFy8BZCGzH9/MaovkArn5Ki+ 5Fdc6gNj32yqh34G4SOeKNHB1VxVOC8Je2fM1dnXFWKnNnMNGMuSGhnhkEApPz78TYS6lQH5nBEr iHIpjma6H6ZMu8dWOtbnKkEQLAYlXHhlv+kp7IYvAcJtGYcMeo8qjd1PYeGsmhloBgiqYAcGC/op df87Ckk= --000000000000e77461060692e29c--