[Rpm] net neutrality back in the news

[Dave Taht]

Dear Bob:

I have always thought the long standing dispute over moving flow
queuing (FQ) into the network has always been about enabling common
carriage for the vast majority of possible use cases for the internet
or not, going all the way back to the fights over it in 1989, and many
discussions prior to that. I haven´t talked about it this way much,
preferring to enable the users first, to make their own choices in
spite of their service providers. I felt showing the general benefit
for making voip, gaming, videoconferencing, web traffic, and bulk
traffic, all co-exist in harmony, and trying to solve the thorny
problems extant in all the things that I had source code to, like
WiFi, was needed, first. Making them these algorithms, so commonly
available, and so obvious, and inevitable, seemed best, rather than
duking it out directly in the political arena, for which I do not have
the stomach or time. I also felt that in a competitive market, fq
would win.

A few days ago John Nagel talked to this point, somewhat. From hackernews:

Animats 3 days ago | root | parent | next [–]

> If everyone played nice, the exponential backoff timers would work as expected,

"As I wrote in 1985, in [1], under "Game Theoretic Aspects of Network
Congestion" and "Fairness in Packet Switching Systems", about fair
queuing, We would like to protect the network from hosts that are not
well-behaved. More specifically, we would like, in the presence of
both well-behaved and badly-behaved hosts, to insure that well-behaved
hosts receive better service than badly-behaved hosts. We have devised
a means of achieving this. The goal of fair queuing is not to improve
network performance overall. The goal of fair queuing is to reward
well-behaved hosts over badly-behaved hosts. If everyone is
well-behaved, the queue lengths are the same, usually 1 or 0, and fair
queuing does little.

There is an inherent conflict between this goal and achieving maximum
data transfer rates. If you try for near 100% utilization, the
problems become much worse. You can run comfortably at maybe 70%. This
was an accepted tradeoff for DoD systems. DoD wants things to keep
working in a crisis, even if normal operation is a bit slower. This is
why I'm not a big fan of HTTP/3. It's a attempt to get about 10% more
performance in the good case, at the cost of considerable extra
complexity and less immunity to gaming the system.

I never wrote about that much at the time, because if I had, people
would have realized earlier that traffic shaping is possible, which
implies that you can sell and bill for bandwidth and quality of
service. We might have ended up with pay per packet."

As for whether this realization has bubbled up as far as the FCC or
not, or the machinations to not deploy our fixes to bufferbloat
without retaining some sort of control as a MITM were conscious by
those fighting it so strongly, I do not know.

I do see the initial reactions to

https://docs.fcc.gov/public/attachments/DOC-397257A1.pdf

seem rather canned so far, and yet reading that post over feels good...

... and I hope that perhaps tomorrow will be a brighter day for the
whole internet, than it is had in a long time.

On Wed, Sep 27, 2023 at 8:33 PM rjmcmahon <rjmcmahon at rjmcmahon.com> wrote:
>
> Common Carriage goes way beyond our lifes. Eli Noam's write up in 1994
> is a good one.
>
> http://www.columbia.edu/dlc/wp/citi/citinoam11.html
>
> Beyond Liberalization II:
> The Impending Doom of Common Carriage
> Eli M. Noam
> Professor of Finance and Economics
> Columbia University, Graduate School of Business
> March 15, 1994
>
> I. Introduction 1
>
> This article argues that the institution of common carriage,
> historically the foundation of the way telecommunications are delivered,
> will not survive. To clarify: "common carriers" (the misnomer often used
> to refer to telephone companies) will continue to exist, but the status
> under which they operate -- offering service on a non-discriminatory
> basis, neutral as to use and user -- will not.
>
> ...
>
> VII. A Contract-Carrier Based Telecommunications System?
>
> The conclusion of the analysis has been that common carriage will erode
> in time, and that a hybrid co-existence will not be stable. This is not
> to say that the common carriers qua carriers will become extinct; many
> of them will remain significant players, but they will conduct their
> business as contract carriers. But common carriage as such will
> disappear. This will not happen overnight, of course. Intermediate
> arrangements can buy several decades of transition time. But the basic
> dynamics will eventually assert themselves.
>
> This conclusion is reached with much regret, because the socially
> positive aspects of common carriage are strong, and because the absence
> to common carriage often means gatekeeper power. But we should not let
> preferences obscure the clarity of analysis.
>
> Bob
> > 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
> >
> > 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, 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.
> >
> > 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.



-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos