From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) (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 7A5603CB39 for ; Thu, 28 Sep 2023 16:36:19 -0400 (EDT) Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-5a22eaafd72so10130677b3.3 for ; Thu, 28 Sep 2023 13:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aterlo.com; s=google; t=1695933379; x=1696538179; 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=XLsopqzrmuTFon0S3w4XRm+bUZXZoyghS/1O6AlLlOs=; b=71DR8hU0iv5L87Ww1AKNjB/PxlcyCAXGwKW3vPuIXDllZHocvcXSaSts1AgCx8zRpp wzdZceJ7CVgjwHdEjBXIOyqmQzHUSAI4aMYPPvP8SaZPuw603biT9Kes5Wl2NqDqqM7C Zqu7gxfG8UiAipxMDbl2hvEfXO2mEYfVvxkNM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695933379; x=1696538179; 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=XLsopqzrmuTFon0S3w4XRm+bUZXZoyghS/1O6AlLlOs=; b=enwvKtM8kKRkPrIiCDj2j8AhkrfCGIto4+qTekobK8Onyw9Mb4pouCEufJ4K2LP5ps COww4nHiwibsVq/4wtf+gOhJ3f4sIcqnR5nAOZtP8rFoM0G0yKiXL1Cpe1wr1735nGoc +Rwv29LAqnbjY1U4eU29s3P0KryVYTuTsU6n4SnCziXxs8wVBKMDfeQViaW4EdUJ9+qW n6zFrxQzsVEH2aV8x2fz/xdS+O2YQF6jkNCjw/nntpPd2Y9zlHRYKxy2L+AvY4XZQzqk X/YVV6s/k5ui7L5cviwnTxWp9GgRP0jbacOcDFyiPa0ukl+8tr3tfbDYnnzJ1HHrIia8 J+IQ== X-Gm-Message-State: AOJu0Yy0aGDTwc0utmRECoT7y/QEZt9FcrNdcYAhYVxrqpEmh0Sk7i0v t3Sq+io5QXSoUBUGjZvmtBfJQkV3q/OjgkJSyHArEmmAkqtJeDPpvvQ= X-Google-Smtp-Source: AGHT+IFdqETKleX8m/d6Ad+5yMyk7sdnIxupByuym7PjHlZ5S5GGV+zB76/i+xprkhGyqR3GKe/O6qeURhqXS7rAEWI= X-Received: by 2002:a25:6b11:0:b0:d7f:8e1f:6df0 with SMTP id g17-20020a256b11000000b00d7f8e1f6df0mr2327983ybc.2.1695933378513; Thu, 28 Sep 2023 13:36:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Austin Date: Thu, 28 Sep 2023 12:36:07 -0800 Message-ID: To: dan Cc: Dave Taht , Rpm , Sebastian Moeller , libreqos , Jamal Hadi Salim , Dave Taht via Starlink , bloat Content-Type: multipart/alternative; boundary="00000000000096e1bc06067142df" Subject: Re: [Rpm] [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: Thu, 28 Sep 2023 20:36:19 -0000 --00000000000096e1bc06067142df Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 28, 2023 at 12:09=E2=80=AFPM dan via LibreQoS < libreqos@lists.bufferbloat.net> wrote: > "(I assume most ISPs want happy customers)." > made me laugh a little. 'Most' by quantity of businesses maybe, but > 'most' in terms of customers being served by puts the Spectrums and > Comcasts in the mix (in the US) and they don't care about happy customers > they care about defacto monopolies in markets so that they don't have to > care about happy customers. That might not be their motivation, but 30 > years of their behavior makes it clear that it's the case. > > > From my perspective, there should be a clear separation between carriers > and last mile delivery.. Even if it's the same company, the rules defini= ng > each really should be different. > > Common Carriers or rather, carrier class services for 'internet', should > be completely neutral. Packets are packets. However, I think it's > important to carve out methods to have dedicated links for real time flow= s > at the carrier level. I don't know what that model looks like exactly, b= ut > being too stubborn about purist NN principals could really hurt VoIP > services if there aren't methods to handle that. I guess I really am > describing 'internet fast lanes' for certain classes of services that we > deem important enough as a whole. not individual ISPs deciding, but rath= er > 'the will of the people' saying VoIP is more important than netflix, you > can carve out dedicated capacity for that. > > Hoo boy. I'm interested in seeing how one can enforce the 'will of the people' -- the application vendors (who are doing everything in their power to prevent ISPs identifying *anything* about the traffic) will certainly not obey such a will, and the ISP can in good faith implement such a prioritization service but have no power to cryptographically authenticate such traffic. This seems a dead end where no one is willing to bear the cost. For the last mile, I'm actually less concerned with pure NN and more > concerned with no-blocking or 'brand' prioritization and required/label > transparency. ie, if an ISP wants to sell a DPI's QoE'd service that say= s > 'videos at 1080p' and that is on the product label clearly and not in sma= ll > print, then that's fine so long as 'videos' is agnostic of the vendor > INCLUDING the ISP's own video products. "100Mbps internet services with > 1080P video $65" for example. "Upgrade to our 100M with 4k video for > +$10/m". With that level of transparency I think that consumer protectio= ns > are well handled. And, because of that transparency, normal market > capitalism mechanisms work. I can say "100Mbps for $65 and full resoluti= on > video" for example. Or "100Mbps Net Neutral service". The secret DPI'= s > QoE shaping is my main concern here, and where I think consumer protectio= n > needs to be pursued. > I don't disagree that consumer protection is vital, but competition might be an easier remedy =E2=80=94 today, for example, mobile providers aren't c= ommon carriers for data, and users flock to WiFi which is cheaper per bit and typically has less fudgery. The above sentiment (we need service specification transparency) is welcome, and largely aligned with my own personal thoughts =E2=80=94 but ve= ry very hard to prove that an ISP is complying with their own labels. NTIA doesn't appear up to it. FCC/FTC certainly aren't at the current level of specification/requirements. > Again however, I think that ISPs should be able to offer dedicated paths > or bandwidth for specific services like VoIP. Services listed in a > publicly determined products list. > That's entirely possible today, but those are carrier services, not BIAS. Consumers don't want them. How are you going to sell them? My $.02 not necessarily reflective of my employer, Jeremy > > > On Thu, Sep 28, 2023 at 1:40=E2=80=AFPM Dave Taht via LibreQoS < > libreqos@lists.bufferbloat.net> wrote: > >> @Sebastian: This is a really great list of what the issues were in the >> EU, and if y'all can repost there, rather than here, perhaps more >> light will be generated outside our circles. >> >> https://news.ycombinator.com/item?id=3D37694306#37694307 >> >> On Thu, Sep 28, 2023 at 12:31=E2=80=AFPM Sebastian Moeller >> wrote: >> > >> > >> > >> > > On Sep 28, 2023, at 18:38, Dave Taht wrote: >> > > >> > > On Wed, Sep 27, 2023 at 11:25=E2=80=AFPM Sebastian Moeller >> wrote: >> > >> >> > >> Hi Dave, >> > >> >> > >> please excuse a number of tangents below ;) >> > > >> > > It would be nice, if as a (dis)organisation... the bufferbloat team >> > > could focus on somehow getting both sides of the network neutrality >> > > debate deeplying understanding the technological problem their >> > > pre-conceptions face, and the (now readily available and inexpensive= ) >> > > solutions that could be deployed, by most ISPs, over a weekend. We a= re >> > > regularly bringing up a few thousand people a week on libreqos (that >> > > we know of), and then of course, there are all the home routers and >> > > CPE that are increasingly capable of doing the right thing. >> > > >> > > The time to try and shift the memes in in the coming days, and weeks= . >> > > >> > > So ya'all being distracting below... aggh... ok, I'll bite. >> > >> > [SM] Sorry to drag you into the weeds... >> > >> > >> > > >> > >> >> > >> >> > >>> On Sep 27, 2023, at 20:21, Dave Taht via Rpm < >> rpm@lists.bufferbloat.net> wrote: >> > >>> >> > >>> Jason just did a beautiful thread as to what was the original sour= ce >> > >>> of the network neutrality >> > >>> bittorrent vs voip bufferbloat blowup. >> > >>> >> > >>> https://twitter.com/jlivingood/status/1707078242857849244 >> > >> >> > >> But the core issue IMHO really was an economic one, the >> over-subscription ratios that worked before torrenting simply did not cu= t >> it any more in an environment when customers actually tried to use their >> contracted access rates "quantitatively". In my outsider perspective an = ISP >> owes its customers the contracted rates (with some slack*) and any sort = of >> over-subscription is a valid economic optimization an ISP might take, IF= F >> that ISP is prepared to rapidly increase segment capacity (or down-grade >> customer plans)) if the deployed over-subscription rate proves to have b= een >> too optimistic. Mind you, most ISPs market plans by access speed (and >> charge more for higher speeds) and hence are somewhat responsible to >> actually deliver (again with some slack) these speeds. >> > > >> > > The average use at peak hours for home broadband is below 5mbits per >> > > subscriber regardless of on a 25mbit or gbit plan. Remarkably, >> > > business plans are less (but more bursty). Oversubscription within a >> > > set of parameters is needed because, in part because upstream >> > > bandwidth to the internet remains expensive (although I hope that co= st >> > > continues to drop rapidly), and in part, because it is needlessly >> > > expensive to provision exactly the contracted rate to the customer. = As >> > > one example, I use the inverse square law as a rule of thumb for >> > > wireless deployments - the range you can get from a 25/10 deployment >> > > is geometrically better than 100/25, and the average bandwidth usage >> > > nearly the same. >> > >> > [SM] +1; hence my argument is not oversubscription per se is >> bad, but that oversubscription needs to be managed and the level of >> oversubscription needs to to be adapted ot he actual usage patterns. I a= m >> sure however that ISPs already actively do that (I assume most ISPs want >> happy customers). >> > >> > >> > > Agreeing on industry standards for what the "slack" should be, might >> be of help. >> > >> > [SM] Not being part of that industry at all I would love to se= e >> that as well, but can not contribute to defining that in any way. >> > >> > >> > > >> > >> >> > >> >> > >> *) Claiming "Up to", only carries that far, if you sell me X and I >> mostly get Y (with Y close to X) and occasionally Z (with Z << X), that = is >> acceptable unless occasionally is "at every late afternoon and evening" >> prime-time. >> > > >> > > We have discussed elsewhere, the idea of a minimum contracted rate >> > > (down to), which is easier to reason about. >> > >> > [SM] Indeed, the German regulator (and I am not saying this is >> the only or best option) decided to require ISPs to give 6 numbers >> pre-contract signing: 3 for up- and 3 for downstream: a maximal (net) ra= te, >> a minimal (net) rate, and a usually achievable (net) rate, all rates wer= e >> defined as IP/TCP goodput to make verification easier on end-users. The >> regulator also defined a measurement regime that end-users can follow to >> check whether the ISP is fulfilling the contract and the law gives remed= ies >> if ISPs do not deliver (either the right to immediately cancel the contr= act >> and/or the right to adapt the monthly payments to the actually delivered >> ratio of the contracted rates*). I think I need to add, that ISPs can se= t >> these numbers freely, but are only allowed to advertise with the maximum >> rate. >> > But if we talk about a single number per direction, minimal >> rate is probably easiest, or something like a "usually achievable rate" >> (that needs to be met or exceeded in say 90% of >=3D 20 measurements or = so). >> > >> > >> > *) In a ironic twist however the regulator so far has not explained ho= w >> deviations in each of the 6 numbers above should be aggregated to get on= e >> single contract rate achievement ratio..., most ISPs took measures into >> their own hands and simply offer customers typically a permanent rebate = of >> 5 EUR or immediate cancelation what ever the customer prefers.... >> > >> > >> > > >> > >> >> > >>> >> > >>> Seeing all the political activity tied onto it since (and now agai= n) >> > >>> reminds of two families at war about an incident that had happened >> > >>> generations and generations before, where the two sides no longer >> > >>> remembered why they hated each other so, but just went on hating, >> and >> > >>> not forgiving, and not moving on. >> > >>> >> > >>> Yes, there are entirely separate and additional NN issues, but the >> > >>> technical problem of providing common carriage between two very >> > >>> different network application types (voip/gaming vs file transfer) >> is >> > >>> thoroughly solved now, >> > >> >> > >> I am not sure this was at the core of the problem, my take i= s >> really that "always-on" and relative upload-heavy torrent simply >> demonstrated painfully for all involved that the old oversubscription >> ratios were not suitable for the changed traffic profiles. I have some >> sympathy for the ISPs here, they certainly did not try to sell their >> customers short (good ISPs try to retain their customers and that works >> best when customers are happy with the service) and having this problem >> appear on many segments at the same time is not a fun place to be, and >> upload was/is often (too) low in DOCSIS segments anyway; but this is why >> e.g. my bit torrent could affect your VoIP, simply by pushing the whole >> segment into upload capacity congestion... (ISPs in theory could fix thi= s >> by plain old QoS engineering, but the issue at hand was with a non-ISP >> VoIP/SIP service and there QoS becomes tricky if the ISP as these packet= s >> need to be identified in a way that is not game-able**) >> > >> > [SM] See my later mail to Jason, I will not claim I know >> Comcast's issues better than him and will accept that self-congestion al= so >> played a major role in the initial problem. Over here in Europe the net >> neutrality debate was kicked of less by an unfortunate confluence of new >> usage profiles and traditional oversibscription ratios and less than ide= al >> packet scheduling, but rather by a series of pretty apparent attempts at >> restricting consumer choice, see eg. >> https://www.accessnow.org/wp-content/uploads/archive/docs/Net_Neutrality= _Ending_Network_Discrimination_in_Europe_Access_v3.pdf >> for an admitted slightly biased position: >> > >> > " =E2=80=A2 Blocking of applications and services: In order to m= aximise >> profits, some ISPs =E2=80=93 that also offer their own services and appl= ications >> online =E2=80=93 exclude certain services and applications of competing = market >> players. The most prominent case of this form of network discrimination = is >> European mobile providers (like Deutsche Telekom) blocking or restrictin= g >> the use of Voice over IP (VoIP) services (like Skype and Viber) for thei= r >> customers.20 >> > >> > =E2=80=A2 Slowing or =E2=80=9Cthrottling=E2=80=9D internet spe= eds: Some ISPs slow down >> specific services (like YouTube) and applications (like Skype), or ask >> users to pay an extra fee to have access to these internet platforms. Gi= ven >> the high latency (delay) sensitivity of many applications, ISPs are able= to >> compromise the correct functioning of these services by slowing them dow= n, >> preventing the services from running properly. Often ISPs =E2=80=93 espe= cially >> telecommunication companies =E2=80=93 do this to favour their own voice = calling >> services over VoIP services, thereby crushing competition. >> > >> > >> > =E2=80=A2 Blocking websites: ISPs often block websites for a n= umber of >> reasons =E2=80=93 to secure their network, or to avoid competition, and = sometimes >> for social, public relations or political reasons. In the UK, for instan= ce, >> Orange Telecom blocked the French digital rights advocacy group, La >> Quadrature du Net=E2=80=99s website on pre-paid mobile accounts.21 >> > >> > =E2=80=A2 Preferential treatment of services and platforms: IS= Ps can >> also impose data caps on internet access contracts while granting data >> allowance exceptions to a company=E2=80=99s own proprietary streaming se= rvices >> (like Deutsche Telekom to its own =E2=80=9CT-Entertain=E2=80=9D).22 They= can (and do) also >> grant preferential treatment to select services =E2=80=93 such as Orange= France >> with the popular music streaming service Deezer23 =E2=80=93 ahead of oth= er >> competitors, effectively imposing anti-competitive limitations on market= s >> such as those for legal online music. Moreover, generally only large, >> well-established companies can afford this preferential treatment, >> resulting in a further stifling of innovation." >> > >> > These look like clearer attempts to monetize the ISP position as >> gate-keeper to his customer's eye-balls (for content providers) as well = as >> gate-keeper to the internet for for paying customers. >> > I find it much harder to have sympathy for the listed examples of ISP >> behavior than the situation of rapidly changing usage pattern posed wher= e >> technical changes needed to be made, but where no attempt at unfair >> monetization was evident, but maybe I am overly sensitive. These are all >> examples that make me personally applaud the EU for its intervention to >> make clear rules what "internet access providers" can and can not do. (T= he >> EU also was quite flexible in applying/interpreting its rules during the >> covid isolation periods, when it made it clear that e.g. treating certai= n >> traffic classes e.g. streaming media to lower priority than video >> conferences was within the neutrality framework as long as it was based = on >> traffic class and not on specific service providers IIRC). >> > >> > >> > >> > > >> > > Torrent problem thoroughly solved with FQ on the path and backpressu= re >> > > from the mac scheduler. >> > > >> > > https://perso.telecom-paristech.fr/drossi/paper/rossi14comnet-b.pdf >> > >> > [SM] Thanks for the link. This is mainly for the >> self-congesrion case? >> > >> > >> > > >> > >> I agree that on a single link we mostly solved the problem (= a >> few corner cases are left on links with very low capacity, where >> essentially we can only manage the pain, not remove it)... >> > >> >> > >> >> > >> **) Which is not rocket science either, a VoIP stream takes ~100 >> Kbps, so in theory an ISP might simply allow each customer say 5 VoIP >> stream equivalents by allowing up to 500Kbps od traffic marked with a >> specific DSCP as higher priority (with higher access probability for the >> shared medium). I am not sayng this is my preferred solution, just sayin= g >> this is a solution that would have been available at the time if I memor= ize >> my docsis capabilities correctly. >> > >> >> > >> >> > >>> and if only all sides recognised at least this >> > >>> much, and made peace over it, and worked together to deploy those >> > >>> solutions, maybe, just maybe, we could find mutually satisfactory >> > >>> solutions to the other problems that plague the internet today, li= ke >> > >>> security, and the ipv6 rollout. >> > >> >> > >> +1. IPv6 is IMHO a prime example where the regulators should >> stop talking softly and start showing the big stick they carry. >> > > >> > > I really would like to see a push for IPv6 mandated as a part of the >> > > BEAD programs. >> > >> > [SM] +1; I am not the biggest IPv6 fan, but that's what we hav= e >> and it is mostly serviceable so let's get this "party started" finally. >> > >> > > >> > >> Heck in Germany we have ISPs that still only supply CG-NATed IPv4 >> addresses only.. (most mass market ISPs do much better in that regard, b= ut >> for the stragglers it would help if the regulator would demand IPv6 with >> PD***). Regarding security, the easiest way to achieve that would be to = put >> some heavy requirements on IoT manufacturers and vendors (like do what y= ou >> please as long as you are local LAN only, but once you reach out into th= e >> cloud you need to fulfill the following list of requirements, with timel= y >> security updates over a reasonable long usage period), however that migh= t >> not be very attractive for politicians/regulators to tackle (active >> regulatory acts tends to get bad press unless something bad happened, bu= t >> even then the press often complains about the acts coming too late, but = I >> digress****) >> > > >> > > There is a separate NRPM going on for the new cybersecurity label at >> > > the FCC. If I had time, and a partner, >> > > we could rework the doc we did a few years ago. It is due oct 6. >> > > >> > >> >> > >> >> > >> ***) Strictly speaking IPv6 is required, since "internet access" is >> defined as reaching all of the internet (as far as in the ISPs power) an= d >> IPv6-only sites are not reachable for the CG-NAT-only customers. But so = far >> the local regulator does not seem to enforce that requirement, or hopefu= lly >> is working on this quietly behind the curtains. >> > >> >> > >> ****) This is not to diss the press, they are doing what they are >> supposed to do, but it just shows that active regulation is a tricky >> business, and a light touch typically "looks better" (even though I see = no >> real evidence it actually works better). >> > >> >> > >>> If anyone here knows anyone more political, still vibrating with 1= 0+ >> > >>> years of outrage about NN on this fronts, on one side or the other= , >> if >> > >>> you could sit them down, over a beer, and try to explain that at t= he >> > >>> start it was a technical problem nobody understood at the time, >> maybe >> > >>> that would help. >> > >> >> > >> So in the EU that debate is essentially settled, there is a >> EU regulation that essentially spills out what ISPs owe their customers = and >> that has become the law of the land. The rationale for required un-biase= d >> service and freedom to select terminal devices is well justified by the >> market ideals of the EU, allowing ISPs to discriminate packets or termin= al >> devices restricts the market and will lead to undesired outcomes. (Fun f= act >> most big players in capitalist societies argue for "free markets" but at >> the same time act to work-around the market mechanism by trying to move = the >> market into an oligo- or even monopoly condition, which is why strong >> regulation is required*****). >> > > >> > > Governments make safer markets feasible. >> > >> > [SM] Yes, I agree, both in markets are a pretty decent tool, >> but need constant maintenance. >> > >> > Regards & Sorry for the tangent >> > Sebastian >> > >> > > >> > >> >> > >> *****) This is akin to professional sports where the audience >> generally accepts that referees are necessary and occasionally need to m= ake >> "painful" calls, as the alternative would be anarchy, but I digress. >> > >> >> > >> Regards >> > >> Sebastian >> > >> >> > >> >> > >>> >> > >>> -- >> > >>> Oct 30: >> https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html >> > >>> Dave T=C3=A4ht CSO, LibreQos >> > >>> _______________________________________________ >> > >>> Rpm mailing list >> > >>> Rpm@lists.bufferbloat.net >> > >>> https://lists.bufferbloat.net/listinfo/rpm >> > >> >> > > >> > > >> > > -- >> > > Oct 30: >> https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html >> > > Dave T=C3=A4ht CSO, LibreQos >> > > <2510.jpeg> >> > >> >> >> -- >> Oct 30: >> https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html >> Dave T=C3=A4ht CSO, LibreQos >> _______________________________________________ >> LibreQoS mailing list >> LibreQoS@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/libreqos >> > _______________________________________________ > LibreQoS mailing list > LibreQoS@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/libreqos > --=20 -- Jeremy Austin Sr. Product Manager Preseem | Aterlo Networks preseem.com Book a Call: https://app.hubspot.com/meetings/jeremy548 Phone: 1-833-733-7336 x718 Email: jeremy@preseem.com Stay Connected with Newsletters & More: *https://preseem.com/stay-connected/* --00000000000096e1bc06067142df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 28, 2023 at 12:09=E2=80= =AFPM dan via LibreQoS <libreqos@lists.bufferbloat.net> wrote:
"(I assume most ISPs= want happy customers)."
made me laugh a little.=C2=A0 'Most= 9; by quantity of businesses maybe, but 'most' in terms of customer= s being served by puts the Spectrums and Comcasts in the mix (in the US) an= d they don't care about happy customers they care about defacto monopol= ies=C2=A0in markets so that they don't have to care about happy custome= rs.=C2=A0 That might not be their motivation, but 30 years of their behavio= r makes it clear that it's the case.


From my perspective, th= ere should be a clear separation between carriers and last mile delivery..= =C2=A0 Even if it's the same company, the rules defining each really sh= ould be different.

Common Carriers or rather, carrier class services= for 'internet', should be completely neutral.=C2=A0 Packets are pa= ckets.=C2=A0 However, I think it's important to carve out methods to ha= ve dedicated links for real time flows at the carrier level.=C2=A0 I don= 9;t know what that model looks like exactly, but being too stubborn about p= urist NN principals could really hurt VoIP services if there aren't met= hods to handle that.=C2=A0 I guess I really am describing 'internet fas= t lanes' for certain classes of services that we deem important enough = as a whole.=C2=A0 not individual ISPs deciding, but rather 'the will of= the people' saying VoIP is more important than netflix, you can carve = out dedicated capacity for that.


<= div>Hoo boy. I'm interested in seeing how one can enforce the 'will= of the people' -- the application vendors (who are doing everything in= their power to prevent ISPs identifying *anything* about the traffic) will= certainly not obey such a will, and the ISP can in good faith implement su= ch a prioritization service but have no power to cryptographically authenti= cate such traffic. This seems a dead end where no one is willing to bear th= e cost.

For the last mile, I'm actually less concerned with= pure NN and more concerned with no-blocking or 'brand' prioritizat= ion and required/label transparency.=C2=A0 ie, if an ISP wants to sell a DP= I's QoE'd service that says 'videos at 1080p' and that is o= n the product label clearly and not in small print, then that's fine so= long as 'videos' is agnostic of the vendor INCLUDING the ISP's= own video products.=C2=A0 "100Mbps internet services with 1080P video= $65" for example.=C2=A0 "Upgrade to our 100M with 4k video for += $10/m".=C2=A0 With that level of transparency I think that consumer pr= otections are well handled.=C2=A0 And, because of that transparency, normal= market capitalism mechanisms work.=C2=A0 I can say "100Mbps for $65 a= nd full resolution video" for example.=C2=A0 =C2=A0Or "100Mbps Ne= t Neutral service".=C2=A0 =C2=A0The secret DPI's QoE shaping is my= main concern here, and where I think consumer protection needs to be pursu= ed.

I don't disagree that con= sumer protection is vital, but competition might be an easier remedy =E2=80= =94 today, for example, mobile providers aren't common carriers for dat= a, and users flock to WiFi which is cheaper per bit and typically has less = fudgery.

The above sentiment (we need service spec= ification transparency) is welcome, and largely aligned with my own persona= l thoughts =E2=80=94 but very very hard to prove that an ISP is complying w= ith their own labels. NTIA doesn't appear up to it. FCC/FTC certainly a= ren't at the current level of specification/requirements.
<= br>Again however, I think that ISPs should be able to offer dedicated paths= or bandwidth for specific services like VoIP.=C2=A0 Services listed in a p= ublicly determined products list.=C2=A0=C2=A0

That's entirely possible today, but those are carrier services= , not BIAS. Consumers don't want them. How are you going to sell them?<= /div>

My $.02 not necessarily reflective of my employer,=
Jeremy
=C2=A0


On Thu, Sep 28, 2023 at 1:40= =E2=80=AFPM Dave Taht via LibreQoS <libreqos@lists.bufferbloat.net> wrot= e:
@Sebastian: T= his is a really great list of what the issues were in the
EU, and if y'all can repost there, rather than here, perhaps more
light will be generated outside our circles.

https://news.ycombinator.com/item?id=3D37694= 306#37694307

On Thu, Sep 28, 2023 at 12:31=E2=80=AFPM Sebastian Moeller <moeller0@gmx.de> wrote:
>
>
>
> > On Sep 28, 2023, at 18:38, Dave Taht <dave.taht@gmail.com> wrote:
> >
> > On Wed, Sep 27, 2023 at 11:25=E2=80=AFPM Sebastian Moeller <moeller0@gmx.de> = wrote:
> >>
> >> Hi Dave,
> >>
> >> please excuse a number of tangents below ;)
> >
> > It would be nice, if as a (dis)organisation... the bufferbloat te= am
> > could focus on somehow getting both sides of the network neutrali= ty
> > debate deeplying understanding the technological problem their > > pre-conceptions face, and the (now readily available and inexpens= ive)
> > solutions that could be deployed, by most ISPs, over a weekend. W= e are
> > regularly bringing up a few thousand people a week on libreqos (t= hat
> > we know of), and then of course, there are all the home routers a= nd
> > CPE that are increasingly capable of doing the right thing.
> >
> > The time to try and shift the memes in in the coming days, and we= eks.
> >
> > So ya'all being distracting below... aggh... ok, I'll bit= e.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[SM] Sorry to drag you into the weeds= ...
>
>
> >
> >>
> >>
> >>> On Sep 27, 2023, at 20:21, Dave Taht via Rpm <rpm@lists.bufferblo= at.net> wrote:
> >>>
> >>> Jason just did a beautiful thread as to what was the orig= inal source
> >>> of the network neutrality
> >>> bittorrent vs voip bufferbloat blowup.
> >>>
> >>> https://twitter.com/jlivi= ngood/status/1707078242857849244
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 But the core issue IMHO really was= an economic one, the over-subscription ratios that worked before torrentin= g simply did not cut it any more in an environment when customers actually = tried to use their contracted access rates "quantitatively". In m= y outsider perspective an ISP owes its customers the contracted rates (with= some slack*) and any sort of over-subscription is a valid economic optimiz= ation an ISP might take, IFF that ISP is prepared to rapidly increase segme= nt capacity (or down-grade customer plans)) if the deployed over-subscripti= on rate proves to have been too optimistic. Mind you, most ISPs market plan= s by access speed (and charge more for higher speeds) and hence are somewha= t responsible to actually deliver (again with some slack) these speeds.
> >
> > The average use at peak hours for home broadband is below 5mbits = per
> > subscriber regardless of on a 25mbit or gbit plan. Remarkably, > > business plans are less (but more bursty). Oversubscription withi= n a
> > set of parameters is needed because, in part because upstream
> > bandwidth to the internet remains expensive (although I hope that= cost
> > continues to drop rapidly), and in part, because it is needlessly=
> > expensive to provision exactly the contracted rate to the custome= r. As
> > one example, I use the inverse square law as a rule of thumb for<= br> > > wireless deployments - the range you can get from a 25/10 deploym= ent
> > is geometrically better than 100/25, and the average bandwidth us= age
> > nearly the same.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[SM] +1; hence my argument is not ove= rsubscription per se is bad, but that oversubscription needs to be managed = and the level of oversubscription needs to to be adapted ot he actual usage= patterns. I am sure however that ISPs already actively do that (I assume m= ost ISPs want happy customers).
>
>
> > Agreeing on industry standards for what the "slack" sho= uld be, might be of help.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[SM] Not being part of that industry = at all I would love to see that as well, but can not contribute to defining= that in any way.
>
>
> >
> >>
> >>
> >> *) Claiming "Up to", only carries that far, if you = sell me X and I mostly get Y (with Y close to X) and occasionally Z (with Z= << X), that is acceptable unless occasionally is "at every late= afternoon and evening" prime-time.
> >
> > We have discussed elsewhere, the idea of a minimum contracted rat= e
> > (down to), which is easier to reason about.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[SM] Indeed, the German regulator (an= d I am not saying this is the only or best option) decided to require ISPs = to give 6 numbers pre-contract signing: 3 for up- and 3 for downstream: a m= aximal (net) rate, a minimal (net) rate, and a usually achievable (net) rat= e, all rates were defined as IP/TCP goodput to make verification easier on = end-users. The regulator also defined a measurement regime that end-users c= an follow to check whether the ISP is fulfilling the contract and the law g= ives remedies if ISPs do not deliver (either the right to immediately cance= l the contract and/or the right to adapt the monthly payments to the actual= ly delivered ratio of the contracted rates*). I think I need to add, that I= SPs can set these numbers freely, but are only allowed to advertise with th= e maximum rate.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0But if we talk about a single number = per direction, minimal rate is probably easiest, or something like a "= usually achievable rate" (that needs to be met or exceeded in say 90% = of >=3D 20 measurements or so).
>
>
> *) In a ironic twist however the regulator so far has not explained ho= w deviations in each of the 6 numbers above should be aggregated to get one= single contract rate achievement ratio..., most ISPs took measures into th= eir own hands and simply offer customers typically a permanent rebate of 5 = EUR or immediate cancelation what ever the customer prefers....
>
>
> >
> >>
> >>>
> >>> Seeing all the political activity tied onto it since (and= now again)
> >>> reminds of two families at war about an incident that had= happened
> >>> generations and generations before, where the two sides n= o longer
> >>> remembered why they hated each other so, but just went on= hating, and
> >>> not forgiving, and not moving on.
> >>>
> >>> Yes, there are entirely separate and additional NN issues= , but the
> >>> technical problem of providing common carriage between tw= o very
> >>> different network application types (voip/gaming vs file = transfer) is
> >>> thoroughly solved now,
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 I am not sure this was at the core= of the problem, my take is really that "always-on" and relative = upload-heavy torrent simply demonstrated painfully for all involved that th= e old oversubscription ratios were not suitable for the changed traffic pro= files. I have some sympathy for the ISPs here, they certainly did not try t= o sell their customers short (good ISPs try to retain their customers and t= hat works best when customers are happy with the service) and having this p= roblem appear on many segments at the same time is not a fun place to be, a= nd upload was/is often (too) low in DOCSIS segments anyway; but this is why= e.g. my bit torrent could affect your VoIP, simply by pushing the whole se= gment into upload capacity congestion... (ISPs in theory could fix this by = plain old QoS engineering, but the issue at hand was with a non-ISP VoIP/SI= P service and there QoS becomes tricky if the ISP as these packets need to = be identified in a way that is not game-able**)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[SM] See my later mail to Jason, I wi= ll not claim I know Comcast's issues better than him and will accept th= at self-congestion also played a major role in the initial problem. Over he= re in Europe the net neutrality debate was kicked of less by an unfortunate= confluence of new usage profiles and traditional oversibscription ratios a= nd less than ideal packet scheduling, but rather by a series of pretty appa= rent attempts at restricting consumer choice, see eg. https://www.accessnow.org/wp-content/uploads/archive/docs/Net_Neutrali= ty_Ending_Network_Discrimination_in_Europe_Access_v3.pdf for an admitte= d slightly biased position:
>
> "=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Blocking of applications an= d services: In order to maximise profits, some ISPs =E2=80=93 that also off= er their own services and applications online =E2=80=93 exclude certain ser= vices and applications of competing market players. The most prominent case= of this form of network discrimination is European mobile providers (like = Deutsche Telekom) blocking or restricting the use of Voice over IP (VoIP) s= ervices (like Skype and Viber) for their customers.20
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Slowing or =E2=80=9Cthrottl= ing=E2=80=9D internet speeds: Some ISPs slow down specific services (like Y= ouTube) and applications (like Skype), or ask users to pay an extra fee to = have access to these internet platforms. Given the high latency (delay) sen= sitivity of many applications, ISPs are able to compromise the correct func= tioning of these services by slowing them down, preventing the services fro= m running properly. Often ISPs =E2=80=93 especially telecommunication compa= nies =E2=80=93 do this to favour their own voice calling services over VoIP= services, thereby crushing competition.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Blocking websites: ISPs oft= en block websites for a number of reasons =E2=80=93 to secure their network= , or to avoid competition, and sometimes for social, public relations or po= litical reasons. In the UK, for instance, Orange Telecom blocked the French= digital rights advocacy group, La Quadrature du Net=E2=80=99s website on p= re-paid mobile accounts.21
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Preferential treatment of s= ervices and platforms: ISPs can also impose data caps on internet access co= ntracts while granting data allowance exceptions to a company=E2=80=99s own= proprietary streaming services (like Deutsche Telekom to its own =E2=80=9C= T-Entertain=E2=80=9D).22 They can (and do) also grant preferential treatmen= t to select services =E2=80=93 such as Orange France with the popular music= streaming service Deezer23 =E2=80=93 ahead of other competitors, effective= ly imposing anti-competitive limitations on markets such as those for legal= online music. Moreover, generally only large, well-established companies c= an afford this preferential treatment, resulting in a further stifling of i= nnovation."
>
> These look like clearer attempts to monetize the ISP position as gate-= keeper to his customer's eye-balls (for content providers) as well as g= ate-keeper to the internet for for paying customers.
> I find it much harder to have sympathy for the listed examples of ISP = behavior than the situation of rapidly changing usage pattern posed where t= echnical changes needed to be made, but where no attempt at unfair monetiza= tion was evident, but maybe I am overly sensitive. These are all examples t= hat make me personally applaud the EU for its intervention to make clear ru= les what "internet access providers" can and can not do. (The EU = also was quite flexible in applying/interpreting its rules during the covid= isolation periods, when it made it clear that e.g. treating certain traffi= c classes e.g. streaming media to lower priority than video conferences was= within the neutrality framework as long as it was based on traffic class a= nd not on specific service providers IIRC).
>
>
>
> >
> > Torrent problem thoroughly solved with FQ on the path and backpre= ssure
> > from the mac scheduler.
> >
> > https://perso.telecom-p= aristech.fr/drossi/paper/rossi14comnet-b.pdf
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[SM] Thanks for the link. This is mai= nly for the self-congesrion case?
>
>
> >
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 I agree that on a single link we m= ostly solved the problem (a few corner cases are left on links with very lo= w capacity, where essentially we can only manage the pain, not remove it)..= .
> >>
> >>
> >> **) Which is not rocket science either, a VoIP stream takes ~= 100 Kbps, so in theory an ISP might simply allow each customer say 5 VoIP s= tream equivalents by allowing up to 500Kbps od traffic marked with a specif= ic DSCP as higher priority (with higher access probability for the shared m= edium). I am not sayng this is my preferred solution, just saying this is a= solution that would have been available at the time if I memorize my docsi= s capabilities correctly.
> >>
> >>
> >>> and if only all sides recognised at least this
> >>> much, and made peace over it, and worked together to depl= oy those
> >>> solutions, maybe, just maybe, we could find mutually sati= sfactory
> >>> solutions to the other problems that plague the internet = today, like
> >>> security, and the ipv6 rollout.
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +1. IPv6 is IMHO a prime example w= here the regulators should stop talking softly and start showing the big st= ick they carry.
> >
> > I really would like to see a push for IPv6 mandated as a part of = the
> > BEAD programs.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[SM] +1; I am not the biggest IPv6 fa= n, but that's what we have and it is mostly serviceable so let's ge= t this "party started" finally.
>
> >
> >> Heck in Germany we have ISPs that still only supply CG-NATed = IPv4 addresses only.. (most mass market ISPs do much better in that regard,= but for the stragglers it would help if the regulator would demand IPv6 wi= th PD***). Regarding security, the easiest way to achieve that would be to = put some heavy requirements on IoT manufacturers and vendors (like do what = you please as long as you are local LAN only, but once you reach out into t= he cloud you need to fulfill the following list of requirements, with timel= y security updates over a reasonable long usage period), however that might= not be very attractive for politicians/regulators to tackle (active regula= tory acts tends to get bad press unless something bad happened, but even th= en the press often complains about the acts coming too late, but I digress*= ***)
> >
> > There is a separate NRPM going on for the new cybersecurity label= at
> > the FCC. If I had time, and a partner,
> > we could rework the doc we did a few years ago. It is due oct 6.<= br> > >
> >>
> >>
> >> ***) Strictly speaking IPv6 is required, since "internet= access" is defined as reaching all of the internet (as far as in the = ISPs power) and IPv6-only sites are not reachable for the CG-NAT-only custo= mers. But so far the local regulator does not seem to enforce that requirem= ent, or hopefully is working on this quietly behind the curtains.
> >>
> >> ****) This is not to diss the press, they are doing what they= are supposed to do, but it just shows that active regulation is a tricky b= usiness, and a light touch typically "looks better" (even though = I see no real evidence it actually works better).
> >>
> >>> If anyone here knows anyone more political, still vibrati= ng with 10+
> >>> years of outrage about NN on this fronts, on one side or = the other, if
> >>> you could sit them down, over a beer, and try to explain = that at the
> >>> start it was a technical problem nobody understood at the= time, maybe
> >>> that would help.
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 So in the EU that debate is essent= ially settled, there is a EU regulation that essentially spills out what IS= Ps owe their customers and that has become the law of the land. The rationa= le for required un-biased service and freedom to select terminal devices is= well justified by the market ideals of the EU, allowing ISPs to discrimina= te packets or terminal devices restricts the market and will lead to undesi= red outcomes. (Fun fact most big players in capitalist societies argue for = "free markets" but at the same time act to work-around the market= mechanism by trying to move the market into an oligo- or even monopoly con= dition, which is why strong regulation is required*****).
> >
> > Governments make safer markets feasible.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[SM] Yes, I agree, both in markets ar= e a pretty decent tool, but need constant maintenance.
>
> Regards & Sorry for the tangent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sebastian
>
> >
> >>
> >> *****) This is akin to professional sports where the audience= generally accepts that referees are necessary and occasionally need to mak= e "painful" calls, as the alternative would be anarchy, but I dig= ress.
> >>
> >> Regards
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sebastian
> >>
> >>
> >>>
> >>> --
> >>> Oct 30: https:= //netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
> >>> Dave T=C3=A4ht CSO, LibreQos
> >>> _______________________________________________
> >>> Rpm mailing list
> >>> Rpm@lists.bufferbloat.net
> >>> https://lists.bufferbloat.net/listinfo/r= pm
> >>
> >
> >
> > --
> > Oct 30: https://netdev= conf.info/0x17/news/the-maestro-and-the-music-bof.html
> > Dave T=C3=A4ht CSO, LibreQos
> > <2510.jpeg>
>


--
Oct 30: https://netdevconf.info/= 0x17/news/the-maestro-and-the-music-bof.html
Dave T=C3=A4ht CSO, LibreQos
_______________________________________________
LibreQoS mailing list
LibreQo= S@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/libreqos
_______________________________________________
LibreQoS mailing list
LibreQo= S@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/libreqos


--
--
Jeremy Austin
Sr. Product Manage= r
Preseem | Aterlo Networks

Phone: 1-833-733-73= 36 x718

Stay Connected with Newsletters & More:=C2=A0https://preseem.com/stay-connecte= d/
--00000000000096e1bc06067142df--