From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8B1913B29D; Sun, 1 Oct 2023 13:08:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1696180111; x=1696784911; i=moeller0@gmx.de; bh=wL9AWmPf1OECqdw/jJZa4HtSizYmo9Ouo29Qp/PSt0o=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=kcwoYRNqMl35QPk/N7VEP1hCsWicfffxolqwjQZ4aqp6bRDYZGheQ6bz5LIgTExHYKKZt2WBKHD 86oNTz/f9mkJ0Yu5MCnFOxf/0gljCt931XTB1JuQACeiuEbu3vrfoUSRM5AQu34//K962Ig8yBoDf srX1RawbfR6gPwom+ZTHJ3uR8bOzkM6j1gRK7e7ee2P6Nt1YhK4s70FJ4VV2BdYgygnLF01iP0j8H +Pj7BSzCVaOSCemLZ6uYWdU3u9NU9ZOrXp/g7Nrq+7T1OXHmTeDvtQBiZ+F5frAaWxl3NQrZQqcal e5ZtsmpP6cegkhnfgvfDwPPftO37nhcnhXCg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([77.0.37.4]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MdNY8-1rM3dH1g3c-00ZRyU; Sun, 01 Oct 2023 19:08:31 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 1 Oct 2023 19:08:30 +0200 Cc: rjmcmahon , Dave Taht via Starlink , Rpm , Jamal Hadi Salim , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <1F27A1D2-95DA-4CA6-9708-307AEA225A77@gmx.de> References: <142199846af097c36920b0d6845379e6@rjmcmahon.com> To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Provags-ID: V03:K1:LCwhDfyQTcg8tbt2O21mdbhP8DJlkpvP4Z3zOsz6nSDtFaaufnf RUJbs8cCmEOGQdC/OZRvmXVxPCuHNXuDHC8tJ3R60yCoDG4YgfXpDkSTYJx+5VxYk6zsDW6 emcdg3I/N7prVuM2MCEJVAq0aEFMwr25e8YR7pIEUop4eMUlQVSUAeJypRQWHkdS6e4K6B6 PlH/fpRzzRErlkumABUMg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:ZA2uWE+OGVs=;J//EJYPGE9jloF/iz1OjSB5dQjj uf2lc1PeNoTUVcIVNH7ZIR7oJEt2KTRM9rXhxluW1UGphfEPzAhWnW005gaza5vbOWAd1ftCx LGbor2OBaOc3IIQE0RnZ1fCTsQutO/Z3oDypOic+WyCsU/n4WZ7kEO0ourwPZarjS/Vn4sPio B90vxBkDpYrso2891RxjbEl4UPNdNnlaJjRNXoxdFUztADGAuinB5NBgXSHQsm7G/QXLA+uCq i5Ta/Y2oz9/JKcVP4COOGvXaD8ixCUIn1wgtr45bMwyIM0+aTwhl3vr25K98Lal0PWjiZVzrG QVcRKMzdg0/w/BqUCbNZ6fLjr5IT+JGBhijaF3w4Wv0FPPVO5QlsAe/QJuLuLBIHXI4p4d+ue DX7wc3PtJKonY6jme4nKIeUJoK2gX2O+GsTkQe1JUhTHxVUo09b/QkLnnrgg0SUfIl3VsvNnA ey20Mw6/K0qrrJLJ2xalkOnks24K+vsnydeZX1XxCdfpV3O6kZ90Shm/7mFEysQr0AllhSZQn XTgOtEMRvOqX9j6bpyhmlyj4+I/1Khk49L/kdKN2k9oJVWTpSP8UTW5JR3EPmV4E1gdAro4Lc aXeiOl8D8ONX/9OqTT1mOc/J7SNMulBa2fId3pUQCqhqW/4lZykeYKw4uttASmRWFUubA8C4D YXN+Oeg7kZ1I5J+gojpwcc9EMw06bkew7GI3EuKPhrNyPsp3+DjoGYepRZJXL7Cb6GvM6/Ep+ pk+7k1jGXUhTlGdEHoCVVqEcuCZSCH9xGcOCjMuBzhJCzZAshJw7wEawPIvVD3et0ZB+q+fSw RR0mOwsWA3BluvY1+lYemdtgVEcxq3+GnlbJK/jrBRd8hEOPvKOGTjdUqn1o7BsiCliGWuf4y IhyNsb1r7FMGyUmS+S1y12onoLac/J2NFVK05hWIh7Z4fJcYnBoVQaISlYPL708KYtxWyoKDY 76gljYJTgJ4e8mt91ISE4WgQ82c= Subject: Re: [Rpm] [Starlink] net neutrality back in the news X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2023 17:08:37 -0000 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 = wrote: >=20 > Dear Bob: >=20 > 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=C2=B4t 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. >=20 > A few days ago John Nagel talked to this point, somewhat. =46rom = hackernews: >=20 > Animats 3 days ago | root | parent | next [=E2=80=93] >=20 >> If everyone played nice, the exponential backoff timers would work as = expected, >=20 > "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. >=20 > 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. >=20 > 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." >=20 > 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. >=20 > I do see the initial reactions to >=20 > https://docs.fcc.gov/public/attachments/DOC-397257A1.pdf >=20 > seem rather canned so far, and yet reading that post over feels = good... >=20 > ... and I hope that perhaps tomorrow will be a brighter day for the > whole internet, than it is had in a long time. >=20 > On Wed, Sep 27, 2023 at 8:33=E2=80=AFPM rjmcmahon = wrote: >>=20 >> Common Carriage goes way beyond our lifes. Eli Noam's write up in = 1994 >> is a good one. >>=20 >> http://www.columbia.edu/dlc/wp/citi/citinoam11.html >>=20 >> 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 >>=20 >> I. Introduction 1 >>=20 >> 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. >>=20 >> ... >>=20 >> VII. A Contract-Carrier Based Telecommunications System? >>=20 >> 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. >>=20 >> 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. >>=20 >> Bob >>> Jason just did a beautiful thread as to what was the original source >>> of the network neutrality >>> bittorrent vs voip bufferbloat blowup. >>>=20 >>> https://twitter.com/jlivingood/status/1707078242857849244 >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >=20 >=20 >=20 > --=20 > Oct 30: = https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html > Dave T=C3=A4ht CSO, LibreQos > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink