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

Thu Oct 5 15:22:05 EDT 2023

Can we please move this discussion off and *only to* the new nnagain
mailing list?
This will be my last cross post.

I also agree strongly with nagle in that flow queuing is least
pessimal.I also do not think we have a universally agreed upon
definition of it. Mine has been:

"When a flow's arrival rate is less than all the other flows departure
rates, it goes out first, otherwise, it is more or less evenly mixed
with the other flows."

This sidesteps bytes vs packets, and is a little inaccurate, but
delightfully short. Fair queuing is just the latter part of the
phrase.

On Sun, Oct 1, 2023 at 10:08 AM Sebastian Moeller <moeller0 at gmx.de> wrote:
>
> Hi Dave,
>
> I really like this argument by John Nagle. It is IMHO complementary (and stronger) to what keep arguing, that far queueing is not most optimal but least pessimal (and close to the best an intermediary node can do with the limited information at hand, anything else needs additional information). What I think is elegant about flow-scheduling is that it taps into essential information for digital communications and hence is hard to exploit (hard, not impossible).
>
>
> > On Sep 28, 2023, at 08:06, Dave Taht via Starlink <starlink at lists.bufferbloat.net> wrote:
> >
> > 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
> > _______________________________________________
> > Starlink mailing list
> > Starlink at lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
>

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