Re: [NNagain] [Starlink] [Rpm] net neutrality back in the news

Re: [NNagain] [Starlink] [Rpm] net neutrality back in the news

[Dave Taht]

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@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@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@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@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

[NNagain] Premium quality retail plans?

[Dave Taht]

IF you have a major fork in the conversation, please change the title to suit.

On Thu, Oct 5, 2023 at 11:53 AM Michael Richardson via Rpm
<rpm@lists.bufferbloat.net> wrote:
>
>
> Mike Conlow via Bloat <bloat@lists.bufferbloat.net> wrote:
>     > As I read this thread and think about the coming debate in the U.S., two
>     > things come to mind:
>
>     > 1. Ofcom is considering
>     > <https://www.ofcom.org.uk/consultations-and-statements/category-1/net-neutrality-review>
>     > a net neutrality "clarification". The first topic in the consultation is
>     > whether ISPs should be allowed to offer "premium quality retail plans". It
>     > doesn't specify the technical implementation, but there would be different
>     > plans for "users who mainly stream" vs "people who use high quality
>     > virtual reality applications". Apparently ISPs feel the existing NN rules
>     > are not clear on whether this is allowed.
>
>     > The question I'm thinking about is do we want an Internet where end user
>     > plans are divided up this way? And if not, is a NN regulation the right
>     > place to put those rules?
>
> Network Neutrality means that all senders are treated the same by the *ISP*
> The ISP doesn't get to decide to prefer some peers over others.
>
> It doesn't mean that the customer can't be given controls to determine what
> traffic they want, and what priority they want to give it.
>
> I think those two categories are totally bonkers.  I would never want to
> subscribe to either service plan, because clearly the ISP thinks they can
> just offload bufferbloat.   We've had protocols to classify traffic for
> decades, but ISPs couldn't be bothered to figure out how to sell that.
>
>     > 2. To the point in the PS of the below email, I would agree things are
>     > mostly working in the EU, and in the US. But things
>     > <https://twitter.com/j0xaf/status/850081406277619712> are
>
> What's twitter?
>
>     > Are NN rules the right place to address this 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 "market" are *mostly* solving
>     > the issue?
>
> The EU bureaucrats are mostly lost in some fantasy land.
> I don't think it will end well.

It is most of the industry, I do not wish to point fingers at any one
org as being confused, or at fault. I would, however, like to inject
technical details into all these conversations.

Moved this
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>
> _______________________________________________
> Rpm mailing list
> Rpm@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

[NNagain] better deployment options

[Dave Taht]

I strongly agree with jonathan's analysis... and moving this to the nnlist

On Thu, Sep 28, 2023 at 9:54 PM Jonathan Morton via Bloat
<bloat@lists.bufferbloat.net> wrote:
>
> > On 29 Sep, 2023, at 1:19 am, David Lang via Bloat <bloat@lists.bufferbloat.net> wrote:
> >
> > Dave T called out earlier that the rise of bittorrent was a large part of the inital NN discussion here in the US. But a second large portion was a money grab from ISPs thinking that they could hold up large paid websites (netflix for example) for additional fees by threatening to make their 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 providing 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 have, over time, fallen under the same umbrella:
>
>
> 1:  Capacity-seeking flows tend to interfere with latency-sensitive 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 solutions are deployed.  It's not usually necessary, for example, to specifically enhance service for latency-sensitive traffic, if FQ does a sufficiently good job.  An increased link rate *does* enhance service quality for both latency-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-flow basis, and the substantially larger number of parallel flows used by swarm traffic.  This also caused subscribers using swarm traffic to impair the service of subscribers who had nothing to do with it.
>
> FQ on a per-flow basis (see problem 1) actually amplifies this effect, and I think it was occasionally used as an argument for *not* deploying FQ.  ISPs' initial response was to outright block swarm traffic where they could identify it, which was then softened to merely throttling it heavily, before NN regulations intervened.  Usage quotas also showed up around this 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 degrading service for another.  Swarm applications nowadays tend to employ altruistic congestion control which deliberately compensates for the large number 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 quality as they used to be.  Usage quotas, however, still remain in use as a profit centre, to the point where an "unlimited" service is a rare and precious specimen in many jurisdictions.
>
>
> 3:  ISPs merged with media distribution companies, creating a conflict of interest in which the media side of the business wanted the internet side to actively favour "their own" media traffic at the expense of "the competition".  Some ISPs began to actively degrade Netflix traffic, in particular by refusing to provision adequate peering capacity at the nodes through 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 forced ISPs to carry Netflix traffic with reasonable levels of service, even though 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 were repealed.
>
> And this type of practice is just the sort of thing that technologies 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 want 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 all attempts to displace it with SCE.
>
>
> All of the above were made more difficult to solve by the monopolistic nature of the Internet service industry.  It is actively difficult for Internet users to move to a truly different service, especially one based on a different link technology.  When attempts are made to increase competition, for example by deploying a publicly-funded network, the incumbents actively sabotage those attempts by any means they can.  Monopolies are inherently customer-hostile, and arguments based on market forces fail in their presence.
>
>  - Jonathan Morton
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



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