From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 3FF0F3CB40 for ; Sat, 30 Sep 2023 08:01:03 -0400 (EDT) Received: by mail-qk1-x734.google.com with SMTP id af79cd13be357-77574dec71bso370425985a.2 for ; Sat, 30 Sep 2023 05:01:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696075262; x=1696680062; darn=lists.bufferbloat.net; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=/wW1V49DSQbHi/XK+cGaxpHLJg1xr7r7UlCyRtUV8fQ=; b=TF6q0uQjPsdqs7iOu0obbypREuhhkW7nFYrNm97Hm7804SlZtUJ/Xe2cS42sB3vHnK juiknLAhHQA9GRn4bU7ZVi8V2TwSArkLHoS2mTyieklA04mvQbWZeVh7TiqNITIqb/74 tsGVuBCe8aezPS5FnG5VwMQR2N6LElMhsNgihgqDebx1okMdi0O9EoKEDzYsYEuNgnyz qBA2Q9YESRG1EM8Y8Py/bgmfz4HQ8dF/9rt3RaFfHFT36ac4ncOqu3yC4DFiVPikSHdx Hg2MG944AZj621nK4hBkrJR3UpeIff3M2vWF15KN8J6lumud+YsFv/7mYpjPcwhzcUkk E50Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696075262; x=1696680062; h=cc: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=/wW1V49DSQbHi/XK+cGaxpHLJg1xr7r7UlCyRtUV8fQ=; b=R3k2SizRZ1qf7YmijTTM8CVFAWZhXHokF+3GNGF6p18A6Jqdc7OOagQBmGwMEw0a1I XgZzlQbgW/YoshBdLcNXfyIJZ7fk7OwpEYgPLMMnOXP4dr5DhDC6zpg4EGeDUhQ1JuX+ AgP6V/wDMf9C3ZQqRcjdlul5yvPznrZLNCYSlj7oYYg5sCvZ4whxF6szsIT7rzbkaRfw dntcAwb7FPC3KWmJpeu/XekqUW7eGGRA0X5Q7uqaIUpmsBzGt/H92v7VnL1kAuya6PLS IyeVipRQY4Q/W/yqgnwg+0ckISl+JxJofrAbb+ZpiSzsal/tTZCaeE0xwPDtbtR+4H69 NciQ== X-Gm-Message-State: AOJu0YwcQHkvFocunLqoXYSJTpdprF7n2rBQM4l1n8qT3uWA/acaB2/Y xkcC85iok1OwNX5xCfGBNbGLdmZKNX5+dlfMxqo= X-Received: by 2002:a05:620a:2488:b0:773:cb13:cb7d with SMTP id i8-20020a05620a248800b00773cb13cb7dmt7170933qkn.48.1696075262531; Sat, 30 Sep 2023 05:01:02 -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> In-Reply-To: From: Frantisek Borsik Date: Sat, 30 Sep 2023 14:00:26 +0200 Message-ID: Cc: Rich Brown , David Lang , Dave Taht via Starlink , libreqos , Jamal Hadi Salim , Rpm , "Livingood, Jason" , bloat , dan Content-Type: multipart/alternative; boundary="0000000000008a18cd0606924b7b" Subject: Re: [LibreQoS] [Rpm] [Bloat] [Starlink] net neutrality back in the news X-BeenThere: libreqos@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Many ISPs need the kinds of quality shaping cake can do List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2023 12:01:03 -0000 --0000000000008a18cd0606924b7b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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): - *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 happened to the packets in transi= t. Yet the relevant academic literature fixates on the local operation of the mechanisms (including Traffic Management), not their global aggregate effect. 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 'carriers' aren'= t > carrying to many places at affordable rates. I've pulled quotes from Lum= en > 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=BC*IX* with x feet of every school, city > hall, and library. I don't care how it's done but this would get abundan= ce > NEAR 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 be 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 start to claw > back even with inferior technology. We've pulled quite a few customers o= ff > 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 t= his >> 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.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 par= t >> of the inital NN discussion here in the US. But a second large portion w= as >> a money grab from ISPs thinking that they could hold up large paid websi= tes >> (netflix for example) for additional fees by threatening to make their >> service less useful to their users (viewing their users as an asset to b= e >> marketed to the websites rather than customers to be satisfied by provid= ing >> them access to the websites) >> >> >> >> I don't know if a new round of "it's not fair that Netflix doesn't pa= y >> us for the bandwidth to service them" would fall flat at this point or n= ot. >> > >> > 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 so= ld >> 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 soluti= ons >> 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 bot= h >> 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 us= ed >> 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 th= ey >> could identify it, which was then softened to merely throttling it heavi= ly, >> before NN regulations intervened. Usage quotas also showed up around th= is >> 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 empl= oy >> altruistic congestion control which deliberately compensates for the lar= ge >> 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 r= are >> and precious specimen in many jurisdictions. >> > >> > >> > 3: ISPs merged with media distribution companies, creating a conflict >> 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 nod= es >> through which Netflix traffic predominated, or by zero-rating (for the >> purpose of usage quotas) traffic from their own media empire while refus= ing >> 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-hosti= le >> 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 w= ant >> 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 = all >> attempts to displace it with SCE. >> > >> > >> > All of the above were made more difficult to solve by the monopolistic >> nature of the Internet service industry. It is actively difficult for >> Internet users to move to a truly different service, especially one base= d >> 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 marke= t >> 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 > --0000000000008a18cd0606924b7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 Gedd= es:

But let's pick one=C2=A0report=C2=A0written by his colleagues = and published by Ofcom (UK telecoms regulator):

  • You cannot conflate =E2=80=98equality o= f [packet] treatment=E2=80=99 with delivering equality of [user application= ] outcomes.=C2=A0Only the latter matters, as ordinary users don=E2= =80=99t care what happened to the packets in transit. Yet the relevant acad= emic literature fixates on the local operation of the mechanisms (including= Traffic Management), not their global aggregate effect.

    • All the best,

    Frank

    Frantisek (Frank) Borsik

    =C2= =A0

    https://www.linkedin.com/in/frantisekborsik

    Signal, T= elegram, WhatsApp: +421919416714=C2=A0

    iMessage, mobile: +420775230885=

    Skype: casioa5= 302ca

    frantisek.borsik@gmail.com


    <= br>
    On Fri,= Sep 29, 2023 at 6:15=E2=80=AFPM dan via Rpm <rpm@lists.bufferbloat.net> wrote:
    ok, lots and lots of great comments here for su= re.=C2=A0=C2=A0

    bandwidth abundance:=C2=A0 Not for most people and I= SPs.=C2=A0 The 'carriers' aren't carrying to many places at aff= ordable 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 Thi= s isn't abundance and it's widespread and it leaves only major=C2= =A0providers that can afford/amortize out 100G transits etc.
    My answer t= o this is one that Dave and I have bounced back and forth is the idea of mi= cro IXs in every municipality and having that somehow tied into access to t= he 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 incentivised to se= ll it.=C2=A0 It takes the better part of a year to get a DIA within 100ft o= f a Lumen hut sometimes...=C2=A0 Heck, it could even be a government progra= m to get an=C2=A0=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 essen= tially every town to competition.

    monopoly.=C2=A0 This is a historic= al thing for most cable and DSL incumbents.=C2=A0 They have enjoyed virtual= monopolies with cable owning population centers and DSL owning the outskir= ts 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 shift into customer satisfaction as a ma= jor part instead of a minor part of their corporate culture to fend off ftt= x and ultra-modern wisps.

    Starlink is not offering significant compe= tition to major carriers.=C2=A0 =C2=A0 Starlink's 1.5 million customers= are at LEAST 90% pulled from other satellite services and small ISPs.=C2= =A0 Spectrum and Comcast's losses to starlink are measured in decimal p= oints.

    Only fttx and ultra-modern wireless tech really threatens the= se incumbents.=C2=A0 Typical wisps aren't putting a dent in these guys,= just scraping the paint off their bumper.=C2=A0 We're pulling customer= s at the scale of 'dozens' for example.=C2=A0 Spectrum's manage= ment doesn'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 w= isps can only exist in places where there is adequate carrier services to s= tart with.=C2=A0 In areas where they spend the money and do the build but t= here aren't good carrier services, those fiber services suck and the wI= SPs start to claw back even with inferior technology.=C2=A0 We've pulle= d quite a few customers off fttx deployments because of this sort of situat= ion.


    On Fri, Sep 29, 2023 at 7:28=E2=80=AFAM Rich Brown <richb.hanover@gmail.c= om> wrote:
    Thank you Jonathan for this cle= ar description of the issues and their history. I wonder if there's a f= ourth one - privacy.

    Rosenworcel's talk https://docs.fcc.gov/= public/attachments/DOC-397257A1.pdf also points out that ISPs might wan= t to monetize our traffic patterns and location data. (This is less of an i= ssue 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 av= ailable by now but I haven't looked...)

    - Rich Brown

    > On Sep 29, 2023, at 12:54 AM, Jonathan Morton via Rpm <rpm@lists.bufferbloat.ne= t> wrote:
    >
    >> On 29 Sep, 2023, at 1:19 am, David Lang via Bloat <bloat@lists.bufferbloa= t.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 portion= was a money grab from ISPs thinking that they could hold up large paid web= sites (netflix for example) for additional fees by threatening to make thei= r 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 providin= g them access to the websites)
    >>
    >> I don't know if a new round of "it's not fair that Ne= tflix 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 have, ov= er time, fallen under the same umbrella:
    >
    >
    > 1:=C2=A0 Capacity-seeking flows tend to interfere with latency-sensiti= ve flows, and the "induced demand" phenomenon means that increase= s in link rate do not in themselves solve this problem, even though they ma= y be sold as doing so.
    >
    > This is directly addressed by properly-sized buffers and/or AQM, and e= ven better by FQ and SQM.=C2=A0 It's a solved problem, so long as the s= olutions are deployed.=C2=A0 It's not usually necessary, for example, t= o specifically enhance service for latency-sensitive traffic, if FQ does a = sufficiently good job.=C2=A0 An increased link rate *does* enhance service = quality for both latency-sensitive and capacity-seeking traffic, provided F= Q is in use.
    >
    >
    > 2:=C2=A0 Swarm traffic tends to drown out conventional traffic, due to= congestion control algorithms which try to be more-or-less fair on a per-f= low basis, and the substantially larger number of parallel flows used by sw= arm traffic.=C2=A0 This also caused subscribers using swarm traffic to impa= ir 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= .=C2=A0 ISPs' initial response was to outright block swarm traffic wher= e they could identify it, which was then softened to merely throttling it h= eavily, before NN regulations intervened.=C2=A0 Usage quotas also showed up= around this time, and were probably related to this problem.
    >
    > This has since been addressed by several means.=C2=A0 ISPs may use FQ = on a per-subscriber basis to prevent one subscriber's heavy traffic fro= m degrading service for another.=C2=A0 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 Effo= rt class DSCPs.=C2=A0 Hence, swarm applications are no longer as damaging t= o service quality as they used to be.=C2=A0 Usage quotas, however, still re= main in use as a profit centre, to the point where an "unlimited"= service is a rare and precious specimen in many jurisdictions.
    >
    >
    > 3:=C2=A0 ISPs merged with media distribution companies, creating a con= flict of interest in which the media side of the business wanted the intern= et side to actively favour "their own" media traffic at the expen= se of "the competition".=C2=A0 Some ISPs began to actively degrad= e Netflix traffic, in particular by refusing to provision adequate peering = capacity at the nodes through which Netflix traffic predominated, or by zer= o-rating (for the purpose of usage quotas) traffic from their own media emp= ire while refusing to do the same for Netflix traffic.
    >
    > **THIS** was the true core of Net Neutrality.=C2=A0 NN regulations for= ced ISPs to carry Netflix traffic with reasonable levels of service, even t= hough they didn't want to for purely selfish and greedy commercial reas= ons.=C2=A0 NN succeeded in curbing an anti-competitive and consumer-hostile= practice, which I am perfectly sure would resume just as soon as NN regula= tions were repealed.
    >
    > And this type of practice is just the sort of thing that technologies = like L4S are designed to support.=C2=A0 The ISPs behind L4S actively do not= want a technology that works end-to-end over the general Internet.=C2=A0 T= hey want something that can provide a domination service within their own w= alled gardens.=C2=A0 That's why L4S is a NN hazard, and why they active= ly resisted all attempts to displace it with SCE.
    >
    >
    > All of the above were made more difficult to solve by the monopolistic= nature of the Internet service industry.=C2=A0 It is actively difficult fo= r Internet users to move to a truly different service, especially one based= on a different link technology.=C2=A0 When attempts are made to increase c= ompetition, for example by deploying a publicly-funded network, the incumbe= nts actively sabotage those attempts by any means they can.=C2=A0 Monopolie= s are inherently customer-hostile, and arguments based on market forces fai= l in their presence.
    >
    > - Jonathan Morton
    >
    > _______________________________________________
    > Rpm mailing list
    > Rpm@lis= ts.bufferbloat.net
    > https://lists.bufferbloat.net/listinfo/rpm

    _______________________________________________
    Rpm mailing list
    Rpm@lists.bu= fferbloat.net
    https://lists.bufferbloat.net/listinfo/rpm
    --0000000000008a18cd0606924b7b--