From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 590D43B2A4; Thu, 28 Sep 2023 02:25:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1695882332; x=1696487132; i=moeller0@gmx.de; bh=wP0e89uPpeMP3y3WHoUzaNkd5+/frPQLshmK8D1e/Io=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=Wjwc7bAD7aM49t1G84WyzahjSXleoGNFkYsALhVBm7YhPboRuKD+lsy7tGM3PwhQrt+eNzSUET3 OH0eRWjNR4EDsNX7murt192GGffpUS0VwN9oD+JEwtE5JVJOgMDgTlGEl5J3X0bc1iwoyhiM934xM zIzzRtKva3bGVtZBcHF7e9Aa8oqv4NfZLgqeGqzFYq+eZcjLkJcN4dYukgAhWqGgELN/D3orosEeA d0PUEDyyGek0M3oYBweZn+Wy2qSnjWptibJhFbRgZBxcXkAUK9+Owi0NwckyC0JscbMXKOYpvpDyk FrV8EPI4QfOiKhAVa6/pANQzacCc1QgT2lWQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MPGVx-1qzoOs3XKP-00PdEg; Thu, 28 Sep 2023 08:25: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: Thu, 28 Sep 2023 08:25:31 +0200 Cc: Dave Taht via Starlink , bloat , Rpm , Jamal Hadi Salim Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Provags-ID: V03:K1:mEfRhH5uxacDrVa8Z/e9xWVGx8+iQ6QIQp6X8cdnoFfEFk+smm/ DXJoO+AHmhIeRvxSrcfMntQJ5ZO7i+NuoeUXQx5qFUUYMPe7WATxG1mKGmmhho2csTWq6QX aV+VhLLrd1Da8K5UsYUGCExJ05/+OxSOJabeGOhJq45yazHBr3lhkCxMRyPOud+J4K4r1g9 oCqJQWnv2qYtznReI7QCA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:q+wEc4mncW8=;+ESi4HWtSgQ4wFZ5ls4IlT+vI2D jAIqZ7asmyyPX+1lHWQ0QnK6pCA+ccVj9WRdOJLbo4Qmh+OtCnk9jq5lIbgf6HH5nJgkcVCPy +vz31yVxWeCAIq/ikbU+V+aTLfss4VftFfC7ECwVsuPKvEpsiwZ8JL6zz/tn5ycTWD2XvLgig lay0vKbZe/BqdL5V26tBrhjnqWosmMFCAuertQEVrjPAUZ0Af4LkEpvGbkcK3bMpDykCvrpWX nEJkk69nZFJeuHGeXaWEZFCR/JQHRRHIq3LImqBbdUehk4kruj3dz6PMxMlXZ8lISTPzu9ZMA VEe4Il4W4lOqhZlrzfVa/62JbRcInInGdbSeMN1Fkj/mIwXcuNhCXdqK0fnTLIrlAxWWQtd3/ JZLfXGWddKlH/9XrPk38sikOV9ybJvTJWh9PUsadFb7cjZt9GcUedx9E46SnwCrmeocsEFx2g N+HnJLNh/wgqUaL6fX+9bqXxGDIECcaJSuzM+sHgO4iSCYkJYkNBWPCPrD5ZFMAIma2WqnAu4 63nTkoierxMVNAE1UgZdwLpgqbN0rRpaeAeUvsxgLebmQUCfXovXtYfnnafuLmFLrYnyWWhVJ pIUDhvVz3WO9pL+WqpeLOdCSE2GnQAfhI9iF2NEX1WirUSuUIzDzMxHgqA35c0rMG1TLwpE3u qSFMP/tCeIbRJ4p9Uj68Yz2V2mNT5stjRlg6G+LtsvQvZYl8FrJRtp9o2P6+4n9euOkgGdlg7 LMPDz2rY1n8WwTlvWEC7X53U8EdO641NPs6CBrrV+U8V502WRS05cizW0SkuQRpIeIQtncqHP 21D9AMXf8zKwxQSmi26jwf/s1Xi2cVyg5wnvrXHZ6GFAr+EV/PUxoh2aRcpcTRZtdXPe/znsc mZ51So4v/Z/kjKmyiIDEHnieem4taI+3qZweOAkxsO/IkAZ318f4x6qa3FwV3hp6asJGU3di2 JB6ZcBhYHwXQGr+HHfhThKJiNOA= Subject: Re: [Starlink] [Rpm] net neutrality back in the news X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2023 06:25:34 -0000 Hi Dave, please excuse a number of tangents below ;) > On Sep 27, 2023, at 20:21, Dave Taht via Rpm = wrote: >=20 > 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 But the core issue IMHO really was an economic one, the = over-subscription ratios that worked before torrenting simply did not = cut it any more in an environment when customers actually tried to use = their contracted access rates "quantitatively". In my outsider = perspective an ISP owes its customers the contracted rates (with some = slack*) and any sort of over-subscription is a valid economic = optimization an ISP might take, IFF that ISP is prepared to rapidly = increase segment capacity (or down-grade customer plans)) if the = deployed over-subscription rate proves to have been too optimistic. Mind = you, most ISPs market plans by access speed (and charge more for higher = speeds) and hence are somewhat responsible to actually deliver (again = with some slack) these speeds. *) Claiming "Up to", only carries that far, if you sell me X and I = mostly get Y (with Y close to X) and occasionally Z (with Z << X), that = is acceptable unless occasionally is "at every late afternoon and = evening" prime-time. >=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, I am not sure this was at the core of the problem, my take is = really that "always-on" and relative upload-heavy torrent simply = demonstrated painfully for all involved that the old oversubscription = ratios were not suitable for the changed traffic profiles. I have some = sympathy for the ISPs here, they certainly did not try to sell their = customers short (good ISPs try to retain their customers and that works = best when customers are happy with the service) and having this problem = appear on many segments at the same time is not a fun place to be, and = upload was/is often (too) low in DOCSIS segments anyway; but this is why = e.g. my bit torrent could affect your VoIP, simply by pushing the whole = segment into upload capacity congestion... (ISPs in theory could fix = this by plain old QoS engineering, but the issue at hand was with a = non-ISP VoIP/SIP service and there QoS becomes tricky if the ISP as = these packets need to be identified in a way that is not game-able**) I agree that on a single link we mostly solved the problem (a = few corner cases are left on links with very low capacity, where = essentially we can only manage the pain, not remove it)... **) Which is not rocket science either, a VoIP stream takes ~100 Kbps, = so in theory an ISP might simply allow each customer say 5 VoIP stream = equivalents by allowing up to 500Kbps od traffic marked with a specific = DSCP as higher priority (with higher access probability for the shared = medium). I am not sayng this is my preferred solution, just saying this = is a solution that would have been available at the time if I memorize = my docsis capabilities correctly. > 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. +1. IPv6 is IMHO a prime example where the regulators should = stop talking softly and start showing the big stick they carry. Heck in = Germany we have ISPs that still only supply CG-NATed IPv4 addresses = only.. (most mass market ISPs do much better in that regard, but for the = stragglers it would help if the regulator would demand IPv6 with PD***). = Regarding security, the easiest way to achieve that would be to put some = heavy requirements on IoT manufacturers and vendors (like do what you = please as long as you are local LAN only, but once you reach out into = the cloud you need to fulfill the following list of requirements, with = timely security updates over a reasonable long usage period), however = that might not be very attractive for politicians/regulators to tackle = (active regulatory acts tends to get bad press unless something bad = happened, but even then the press often complains about the acts coming = too late, but I digress****)=20 ***) Strictly speaking IPv6 is required, since "internet access" is = defined as reaching all of the internet (as far as in the ISPs power) = and IPv6-only sites are not reachable for the CG-NAT-only customers. But = so far the local regulator does not seem to enforce that requirement, or = hopefully is working on this quietly behind the curtains. ****) This is not to diss the press, they are doing what they are = supposed to do, but it just shows that active regulation is a tricky = business, and a light touch typically "looks better" (even though I see = no real evidence it actually works better). > 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. So in the EU that debate is essentially settled, there is a EU = regulation that essentially spills out what ISPs owe their customers and = that has become the law of the land. The rationale for required = un-biased service and freedom to select terminal devices is well = justified by the market ideals of the EU, allowing ISPs to discriminate = packets or terminal devices restricts the market and will lead to = undesired outcomes. (Fun fact most big players in capitalist societies = argue for "free markets" but at the same time act to work-around the = market mechanism by trying to move the market into an oligo- or even = monopoly condition, which is why strong regulation is required*****). *****) This is akin to professional sports where the audience generally = accepts that referees are necessary and occasionally need to make = "painful" calls, as the alternative would be anarchy, but I digress. Regards Sebastian >=20 > --=20 > Oct 30: = https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html > Dave T=C3=A4ht CSO, LibreQos > _______________________________________________ > Rpm mailing list > Rpm@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/rpm