From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 057D03B29E; Sat, 30 Sep 2023 13:35:46 -0400 (EDT) Received: by mail-pg1-x52d.google.com with SMTP id 41be03b00d2f7-573e67cc6eeso10471335a12.2; Sat, 30 Sep 2023 10:35:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696095346; x=1696700146; darn=lists.bufferbloat.net; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=lrdsRbu0m+VCUFvI/xCfJMSNqyKVjVLEUetxdjscgK8=; b=PzdB2yPP77BQgoMVkiVF26NfgN93vUk//QaUqnoZVB/mQmXlkQUPPhLZ6XRprMrLBm w9HEs4HRAiW74dAERZNjZrmdVZp4nW5NFtyjgX4YgU53AKVxENxf4ZeGq1wa7MueEkO2 ZSNqFbtEA4TYz5ij+7Of8U/asK7pYkBvMvHcjhzwzPkrVYf8Po4iigJB9LEIfvZbhIvG wiU4EnuKEgdohHBsZt1UdSWaa6fXLCHM0sxCVSAmtW7hNUXs9qXJLRmhue1MPdCONelF nFURKSdbzpgBErPD8Lo7qGGXsK57Qpu1XQJ4pzowwFENyCTZ/UBfnMXd/AA0SYuaC9og gzvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696095346; x=1696700146; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lrdsRbu0m+VCUFvI/xCfJMSNqyKVjVLEUetxdjscgK8=; b=U41ncuk9oTKEnEUZoXxUyERH+GdEDfkcNAh9lZfSCOHpByeJ97UlsVcZ+x+XSWqgEY ifw4GeZRClqCeZ0T3rKRV6Tm8CDYX8uu3m46bbvk4blLNxb/2cBdBOPJozTkPRmCzPwX BoLq3SoTe8XpNJNTYvaQSlsOMnATfRdrkIVGoArnexa4zRe+H0mDRxUgFVciAxWF5fkb N70EEff2KvLVBcRgIUSBGST7RviMa0EhmymGeqBi/H1DwdCGCyYeuf7hfqL+4UauZIJQ pdJ8mc7SxohjcJII3IN+k5OrzOXE+GtXXfLs8RloCLbwLI64vbI0Mml5xTILB2USbPdF RzHA== X-Gm-Message-State: AOJu0YxMM1iGVGdGV2u0gfNVEvYkBn8BlStn+O09pprJ69RRzK9iSjCQ 4pnX1cgimRu+n+RLbx6ugoYUzEs/dVYi+AvKu/Q= X-Google-Smtp-Source: AGHT+IEhKbEWEQyzT4XkCP47TtUduvzq0vEy/+tWCiztUS4usXKWGBXNOEWkr3rf3ohxLFbFZzGKHrr+xYrJN+BbQxo= X-Received: by 2002:a05:6a20:6a09:b0:14c:910d:972d with SMTP id p9-20020a056a206a0900b0014c910d972dmr8097647pzk.12.1696095345547; Sat, 30 Sep 2023 10:35:45 -0700 (PDT) MIME-Version: 1.0 References: <5so3r00n-31pn-14s7-7775-08731s3s551r@ynat.uz> <7508FE73-A154-4CBA-984C-748A80C5FFEC@gmail.com> <039490DA-48A7-4AE2-B00F-AA2A260FB747@gmail.com> <3F6D16C8-530E-4066-8B6A-C0644B3C2D2C@gmx.de> <4129491C-FFC7-4E5E-A5A4-8CBE9B5C5255@gmx.de> In-Reply-To: From: Dave Taht Date: Sat, 30 Sep 2023 10:35:33 -0700 Message-ID: To: Sebastian Moeller Cc: Mike Conlow , Rpm , bloat , Dave Taht via Starlink Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Rpm] [LibreQoS] [Bloat] [Starlink] 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 17:35:47 -0000 Despite the sturm und drang here if you google for network neutrality there was a lot of press coverage 4 days ago. ... and mostly, silence, on the twitters at least. How is mastodon or other social media? I couldn=C2=B4t help but notice that this was essentially, Diane Feinstein=C2=B4s last press release (she died yesterday): https://www.feinstein.senate.gov/public/index.cfm/press-releases?id=3DC6FFF= 484-16F1-4CC9-9836-F36446C3B33D On Sat, Sep 30, 2023 at 8:23=E2=80=AFAM Dave Taht wro= te: > > The starlink list was not originally cc=C2=B4d and yet since I think this > debate concerns that also, I have added the cc back. Carry on! > > On Sat, Sep 30, 2023 at 8:20=E2=80=AFAM Sebastian Moeller via LibreQoS > wrote: > > > > Hi Mike, > > > > [I took the liberty to remove some individual address from the Cc, as I= assume most/all already be covered by the lists] > > > > > > > On Sep 30, 2023, at 16:41, Mike Conlow wrote= : > > > > > > First, a thank you to Dave, and lots of you all, for longtime shepher= ding of this community and efforts to make the Internet better. > > > > > > As I read this thread and think about the coming debate in the U.S., = two things come to mind: > > > > > > 1. Ofcom is considering a net neutrality "clarification". The first t= opic in the consultation is whether ISPs should be allowed to offer "premiu= m quality retail plans". It doesn't specify the technical implementation, b= ut there would be different plans for "users who mainly stream" vs "people = who use high quality virtual reality applications". Apparently ISPs feel th= e existing NN rules are not clear on whether this is allowed. > > > > [SM] Not sure this is not simply an attempt of using regulatory= divergence from the EU (IMHO for no good reason or outcome)... Also und er= the existing EU rules ISPs are arguably already free to treat the whole cl= ass of latency sensitive VR to lower delay than bulk streaming as long as t= hey do son consistently and not based on commercial relationships with the = senders... > > During the covid19 lock downs the EU offered clarification on the regul= ation that really drove home the do not discriminate inside of a specific t= raffic class, and define classes by purely technical not economical paramet= ers. That said, I always like to look at data and hence am happy to the the= UK apparently prepping to run that experiment (I am also happy not to live= there right now not having to prticipate in said experiment*). > > > > > > *) Other than that the british islands offer a lot of really great plac= es I certainly would like to live at, but I digress. > > > > > > > > The question I'm thinking about is do we want an Internet where end u= ser plans are divided up this way? > > > > [SM] Personally, I consider internet access infrastructure and = do not think this looks like a good way forward. > > > > > And if not, is a NN regulation the right place to put those rules? > > > > [SM] Could well be, but depends on the framing, no? > > > > > > > > 2. To the point in the PS of the below email, I would agree things ar= e mostly working in the EU, and in the US. But things are broken in Germany= to the point where consumers have a degraded Internet experience because t= heir ISP won't provision enough interconnection. > > > > [SM] This a very peculiar case of the local incumbent Deutsche = Telekom (DTAG) (all in all a pretty competent ISP that runs a tight ship in= its network and tends to follow regulations to the letter (not however nec= essarily to the intent, but they are not different from other corporations = of similar size)). DTAG is large enough to qualify as tier 1 (T1) ISP that = is, to the best of our knowledge they do not pay anybody for transit and pe= er with all other T1-ISPs, they also have a relative large share of eye-bal= ls in one of Europes larger and profitable markets. They (as did AT&T and V= erizon in the US and probably other ISPs in similar positions as well) that= most of their users traffic was within network (e.g. from German companies= hosted/homed by DTAG) or via important partners like Google that have dece= nt peering links (unclear whether/if Google actually is charged for that) b= ut that there is a considerable number of services that reach DTAG eye-ball= s via their transit, that is essentially via one of the other T1-ISPs (I si= mplify here, I have no insight in the actual bisiness relationships between= all players). And now DTAG basically instructed its generally capable netw= ork team to simply manage the size of the peering links with the big transi= t-providers carefully so that they never fully clogg, but clearly see incre= ased packet loss and queueing delay during prime time. That in turn is clea= rly a competition problem if streaming service A judders/jitters/and buffer= s jumps between quality tiers while streaming service B smoothly and boring= ly just streams at the desired resolution. Now Telekom is happy to offer se= rvice A a product they call "internet transit" but that is priced pretty hi= gh (I have seen some comparative numbers for transit pricing in Germany I a= m not permitted to share or reveal more about) so high in fact that no cont= ent provider that can afford more than a single transit provider would use = for anything but reaching DTAG eye-balls or closely related ones (like in t= he past SwissCom). > > This behaviour is not s secret but evades regulatory action, because it= does not openly violate the EU regulation which in the BEREC interpretatio= n does not really cover the interconnection side. DTAG is careful enough to= not purposefully target specific potential customers but simply treats all= traffic coming in/out via "other transit than its own" as "has to tolerate= overheated links during primetime". > > > > > > > Are NN rules the right place to address this > > > > [SM] They could well be the actual text of the 2015/2120 does n= ot make a distinction between access and interconnection. But this is a tri= cky field and will directly affect parts of larger ISP's core business so I= do not see this happen in the EU anytime soon, unless ISPs like Telekom cl= early abuses this in a way that is too obvious... ATM it is mostly telecom,= but I believe any of the big old monopoly incumbents likely is big enough = in its home market to pull of a stunt like this, so there is the potential = of someone over doing it... > > > > > and make sure it doesn't happen in the US? Or is one bad actor across= the EU and US the cost of doing business and the Internet ecosystem and "m= arket" are mostly solving the issue? > > > > [SM] As happy as I am to diss DTAG for that behavior (I am also= happy to praise it in ears where it shows exemplary behavior) DTAG is not = alone in that business acumen, I think that some of the big US telco's dod/= do exactly the same, but unlike telekom I have no evidence. > > > > > > Regards > > Sebastian > > > > P.S.: I was a customer at DTAG for several years and I did not notice t= he conscious under-peering with the other T1 ISPs in my day to day usage, s= o while the issue clearly and measurably exists it is not an issue that nor= mal users will encounter often and are also unlikely to properly root-cause= (the blame will likely land by my example service A above). > > > > > > > > > > > > > > > > On Sat, Sep 30, 2023 at 8:19=E2=80=AFAM Sebastian Moeller via Rpm wrote: > > > Hi Frantisek, > > > > > > > On Sep 30, 2023, at 14:00, Frantisek Borsik via Rpm wrote: > > > > > > > > Back then in 2015, when NN was enacted by Wheeler & CO, there was a= great body of work (IMHO) done on this subject by Martin Geddes: > > > > https://www.martingeddes.com/1261-2/ > > > > > > > > But let's pick one report written by his colleagues and published b= y Ofcom (UK telecoms regulator): > > > > > > > > =E2=80=A2 You cannot conflate =E2=80=98equality of [packet] t= reatment=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 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 re= gulations in eu regulation 2015/2120: > > > > > > [...] > > > (8) > > > When providing internet access services, providers of those services = should treat all traffic equally, without discrimination, restriction or in= terference, independently of its sender or receiver, content, application o= r service, or terminal equipment. According to general principles of Union = law and settled case-law, comparable situations should not be treated diffe= rently and different situations should not be treated in the same way unles= s 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 trans= mission quality responding to the objectively different technical quality o= f service requirements of specific categories of traffic, and thus of the c= ontent, applications and services transmitted. Reasonable traffic managemen= t measures applied by providers of internet access services should be trans= parent, non-discriminatory and proportionate, and should not be based on co= mmercial considerations. The requirement for traffic management measures to= be non-discriminatory does not preclude providers of internet access servi= ces from implementing, in order to optimise the overall transmission qualit= y, traffic management measures which differentiate between objectively diff= erent categories of traffic. Any such differentiation should, in order to o= ptimise overall quality and user experience, be permitted only on the basis= of objectively different technical quality of service requirements (for ex= ample, in terms of latency, jitter, packet loss, and bandwidth) of the spec= ific categories of traffic, and not on the basis of commercial consideratio= ns. Such differentiating measures should be proportionate in relation to th= e purpose of overall quality optimisation and should treat equivalent traff= ic equally. Such measures should not be maintained for longer than necessar= y. > > > (10) > > > Reasonable traffic management does not require techniques which monit= or the specific content of data traffic transmitted via the internet access= service. > > > (11) > > > Any traffic management practices which go beyond such reasonable traf= fic management measures, by blocking, slowing down, altering, restricting, = interfering with, degrading or discriminating between specific content, app= lications or services, or specific categories of content, applications or s= ervices, should be prohibited, subject to the justified and defined excepti= ons laid down in this Regulation. Those exceptions should be subject to str= ict interpretation and to proportionality requirements. Specific content, a= pplications and services, as well as specific categories thereof, should be= protected because of the negative impact on end-user choice and innovation= of blocking, or of other restrictive measures not falling within the justi= fied exceptions. Rules against altering content, applications or services r= efer to a modification of the content of the communication, but do not ban = non-discriminatory data compression techniques which reduce the size of a d= ata file without any modification of the content. Such compression enables = a more efficient use of scarce resources and serves the end-users=E2=80=99 = interests by reducing data volumes, increasing speed and enhancing the expe= rience of using the content, applications or services concerned. > > > (12) > > > Traffic management measures that go beyond such reasonable traffic ma= nagement measures may only be applied as necessary and for as long as neces= sary to comply with the three justified exceptions laid down in this Regula= tion. > > > [...] > > > > > > There really is little IMHO that can be brought against these, all pr= etty fair and reasonable. What it does is accept that internet access is es= sential infrastructure and that hence access needs to be as well regulated = as access to water, electricity, gas, streets, ... . Yes this has some cons= equences of what ISPs can and can not do. But this is normal "cost of busin= ess". I for one am quite happy about this regulation existing as locally it= did away with some (not all) shenanigans of some ISPs that were clearly no= t 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 mak= es me think harsher regulation might be required (on consultans about how m= uch they are allowed to massage the facts ;) ). > > > > > > Regards > > > Sebastian > > > > > > P.S.: Of course if we look close enough we surely can find corner-cas= es where either the EU regulations or the translation into national law res= ult in less desirable outcomes, but "nothing is perfect" and all in all the= regulations seem to be "good enough". With the caveat that explicitly excl= uding ISP interconnect from the regulations BEREC essentially pointed the w= ay for ISPs wanting to monetize their eye-balls twice to do so via intercon= nects, but that only works for the 800 pound gorillas and generally is not = a game smaller ISPs can play. I do understand why BEREC wants to stay out o= f the interconnection issue, as this is rather complicated and the market s= eems to generally work okay-ish (that is not badly enough to make intervent= ion a hot-button issue for voters and hence politicians). > > > > > > > > > > > > > > > > > All the best, > > > > > > > > Frank > > > > > > > > Frantisek (Frank) Borsik > > > > > > > > > > > > > > > > https://www.linkedin.com/in/frantisekborsik > > > > > > > > Signal, Telegram, WhatsApp: +421919416714 > > > > > > > > iMessage, mobile: +420775230885 > > > > > > > > Skype: casioa5302ca > > > > > > > > frantisek.borsik@gmail.com > > > > > > > > > > > > > > > > On Fri, Sep 29, 2023 at 6:15=E2=80=AFPM dan via Rpm wrote: > > > > ok, lots and lots of great comments here for sure. > > > > > > > > bandwidth abundance: Not for most people and ISPs. The 'carriers'= aren't carrying to many places at affordable rates. I've pulled quotes fr= om Lumen and Zayo at over $5k/month/gig. We typically pay 900-1400 for a g= ig 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 fort= h is the idea of micro IXs in every municipality and having that somehow ti= ed into access to the ROW in counties etc. Not fully hashed out, but the f= iber is in the ground, it could be sold, but the carriers are not well ince= ntivised to sell it. It takes the better part of a year to get a DIA withi= n 100ft of a Lumen hut sometimes... Heck, it could even be a government pr= ogram to get an =CE=BCIX with x feet of every school, city hall, and librar= y. 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. This is a historical thing for most cable and DSL incumb= ents. They have enjoyed virtual monopolies with cable owning population ce= nters and DSL owning the outskirts and there is no product darwinism here w= here customer satisfaction is a pressure. That may not be the future but i= t 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 cul= ture 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 sat= ellite 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 inc= umbents. Typical wisps aren't putting a dent in these guys, just scraping = the paint off their bumper. We're pulling customers at the scale of 'dozen= s' for example. Spectrum's management doesn't know we exist we're such a s= mall threat to them. > > > > > > > > But to further the point here, these fttx and ultra-modern wisps ca= n only exist in places where there is adequate carrier services to start wi= th. 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 cla= w 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 the= ir history. I wonder if there's a fourth one - privacy. > > > > > > > > Rosenworcel's talk https://docs.fcc.gov/public/attachments/DOC-3972= 57A1.pdf also points out that ISPs might want to monetize our traffic patte= rns and location data. (This is less of an issue in the EU, but the US rema= ins a Wild West in this regard.) > > > > > > > > I am hopeful that the FCC will include this in their NPRM (which mu= st be available by now but I haven't looked...) > > > > > > > > - Rich Brown > > > > > > > > > On Sep 29, 2023, at 12:54 AM, Jonathan Morton via Rpm wrote: > > > > > > > > > >> On 29 Sep, 2023, at 1:19 am, David Lang via Bloat wrote: > > > > >> > > > > >> Dave T called out earlier that the rise of bittorrent was a larg= e 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 w= ebsites (netflix for example) for additional fees by threatening to make th= eir 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 provid= ing 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 = or not. > > > > > > > > > > I think there were three more-or-less separate concerns which hav= e, over time, fallen under the same umbrella: > > > > > > > > > > > > > > > 1: Capacity-seeking flows tend to interfere with latency-sensiti= ve flows, and the "induced demand" phenomenon means that increases in link = rate do not in themselves solve this problem, even though they may be sold = 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 solut= ions are deployed. It's not usually necessary, for example, to specificall= y enhance service for latency-sensitive traffic, if FQ does a sufficiently = good job. An increased link rate *does* enhance service quality for both l= atency-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-f= low basis, and the substantially larger number of parallel flows used by sw= arm traffic. This also caused subscribers using swarm traffic to impair th= e 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. 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 t= his 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 de= grading service for another. Swarm applications nowadays tend to employ al= truistic congestion control which deliberately compensates for the large nu= mber 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 qual= ity as they used to be. Usage quotas, however, still remain in use as a pr= ofit centre, to the point where an "unlimited" service is a rare and precio= us specimen in many jurisdictions. > > > > > > > > > > > > > > > 3: 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 expense of "the= competition". Some ISPs began to actively degrade Netflix traffic, in par= ticular by refusing to provision adequate peering capacity at the nodes thr= ough which Netflix traffic predominated, or by zero-rating (for the purpose= of usage quotas) traffic from their own media empire while refusing to do = the same for Netflix traffic. > > > > > > > > > > **THIS** was the true core of Net Neutrality. 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 reasons.= NN succeeded in curbing an anti-competitive and consumer-hostile practice= , which I am perfectly sure would resume just as soon as NN regulations wer= e repealed. > > > > > > > > > > And this type of practice is just the sort of thing that technolo= gies like L4S are designed to support. The ISPs behind L4S actively do not= want a technology that works end-to-end over the general Internet. They w= ant 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 al= l 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. It is actively difficult fo= r Internet users to move to a truly different service, especially one based= on a different link technology. When attempts are made to increase compet= ition, for example by deploying a publicly-funded network, the incumbents a= ctively sabotage those attempts by any means they can. Monopolies are inhe= rently 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 > > > > > > _______________________________________________ > > > Rpm mailing list > > > Rpm@lists.bufferbloat.net > > > https://lists.bufferbloat.net/listinfo/rpm > > > > _______________________________________________ > > LibreQoS mailing list > > LibreQoS@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/libreqos > > > > -- > Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.h= tml > Dave T=C3=A4ht CSO, LibreQos -- Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.htm= l Dave T=C3=A4ht CSO, LibreQos