[LibreQoS] [Rpm] net neutrality back in the news

Dave Taht dave.taht at gmail.com
Thu Sep 28 12:38:00 EDT 2023

On Wed, Sep 27, 2023 at 11:25 PM Sebastian Moeller <moeller0 at gmx.de> 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 are
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.

> > On Sep 27, 2023, at 20:21, Dave Taht via Rpm <rpm at lists.bufferbloat.net> wrote:
> >
> > Jason just did a beautiful thread as to what was the original source
> > 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 cut 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, IFF that ISP is prepared to rapidly increase segment capacity (or down-grade customer plans)) if the deployed over-subscription rate proves to have been 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 cost
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.

Agreeing on industry standards for what the "slack" should be, might be of help.

> *) 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.

> >
> > 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 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 is 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 this 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 packets need to be identified in a way that is not game-able**)

Torrent problem thoroughly solved with FQ on the path and backpressure
from the mac scheduler.


>         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 saying this is a solution that would have been available at the time if I memorize 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, like
> > 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.

> 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 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 you please as long as you are local LAN only, but once you reach out into the cloud you need to fulfill the following list of requirements, with timely security updates over a reasonable long usage period), however that might not be very attractive for politicians/regulators to tackle (active regulatory acts tends to get bad press unless something bad happened, but 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) and 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 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 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 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.
>         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-biased service and freedom to select terminal devices is well justified by the market ideals of the EU, allowing ISPs to discriminate packets or terminal devices restricts the market and will lead to undesired 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 condition, which is why strong regulation is required*****).

Governments make safer markets feasible.

> *****) This is akin to professional sports where the audience generally accepts that referees are necessary and occasionally need to make "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äht CSO, LibreQos
> > _______________________________________________
> > Rpm mailing list
> > Rpm at 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äht CSO, LibreQos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2510.jpeg
Type: image/jpeg
Size: 66803 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/libreqos/attachments/20230928/78f795e7/attachment-0001.jpeg>

More information about the LibreQoS mailing list