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 <rjmcma...@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 _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
