From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1E5F63B29E; Fri, 29 Sep 2023 09:28:22 -0400 (EDT) Received: by mail-qk1-x734.google.com with SMTP id af79cd13be357-77432add7caso622342185a.2; Fri, 29 Sep 2023 06:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695994101; x=1696598901; darn=lists.bufferbloat.net; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=R225TQqb35gGSLv5des5Nq0Z/kfppzUbX+JVyCNrKbc=; b=F6jDHyeRXrCwZYlT8MSa5JGjq7iNrAlyXpvPxgQsa1ONpH1L+FgqFN/9g9oUo9kHfi +kZH+zDP1RUNHB7/ka09mlurFRZs0siCpbzQ4yIz2/wMgefN7CyWfcHrCXmKbWBeaWGQ LwoyDhpzKJKDC0U08hJJ//J+vmuXeZ/0vwA239drvDRz4T3U2RDLmmpMUqEvnj+HQZfe Y7z7Or1SWFmk4FpvZ9aqfv4zkqXVi/ecNqi3CJKaOr9pEXWV0Tj/hYhqK0ywS29/8IyO kLMnh5T0CqLE7f5NLN/XXF8YU+Wsg0N/rGcU2zgHvlXSbPGPCdi7te3nD3uLZSPORB3A v0aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695994101; x=1696598901; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=R225TQqb35gGSLv5des5Nq0Z/kfppzUbX+JVyCNrKbc=; b=n1P3Pw2zwBSN/nDGReBxOvdgDLaOrdWVf8rKuZz60mghpSgKH+zlDp0ZTQFvNe62zp 6K+igz/7B9hIllfyjP9uQmMFFaEEBiHbuYVxVyow0w5gJf/v21EXhparleoBAVaPQG9R qkzLsHpgyBh544USvg7sOphYcq9mXrLKNReXRHZPJPxCKvG5jpFTpknjLfGcvJcv5EIh 5W3gHsorvVJdVMz4eds6HRJUMSj1A+Y+UQemvixOyA0xT269zKlz6IZaonVPzhJVqS0V RFfBOPX0a7cB38Xs6txU8ykmBt8xdUO8LGjyuQWj9amO8UVWItocQkRQZ+U0SYNGHdkH V6DQ== X-Gm-Message-State: AOJu0YwjdmxIySaRxsuKkMtzoHQ5fpFMuWJCZi4nGXlEbJc0FgF+C2GO jspp4PmliMw/mbfSMLjeuio= X-Google-Smtp-Source: AGHT+IElyVg9w7nDIpxLMc0BDfJapRjJDzamSuNLT1WCfoAvyJw4oHRbd45ugOB+MGXcFdw8NXPL6A== X-Received: by 2002:a05:620a:4085:b0:775:68c8:79f7 with SMTP id f5-20020a05620a408500b0077568c879f7mr5220682qko.0.1695994101255; Fri, 29 Sep 2023 06:28:21 -0700 (PDT) Received: from smtpclient.apple ([198.55.239.10]) by smtp.gmail.com with ESMTPSA id k22-20020a05620a143600b007742b1adeebsm4626613qkj.94.2023.09.29.06.28.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Sep 2023 06:28:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) From: Rich Brown In-Reply-To: <7508FE73-A154-4CBA-984C-748A80C5FFEC@gmail.com> Date: Fri, 29 Sep 2023 08:28:00 -0400 Cc: David Lang , Rpm , dan , Jamal Hadi Salim , libreqos , Dave Taht via Starlink , "Livingood, Jason" , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <039490DA-48A7-4AE2-B00F-AA2A260FB747@gmail.com> References: <5so3r00n-31pn-14s7-7775-08731s3s551r@ynat.uz> <7508FE73-A154-4CBA-984C-748A80C5FFEC@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3696.120.41.1.4) Subject: Re: [Rpm] [Bloat] [Starlink] [LibreQoS] 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: Fri, 29 Sep 2023 13:28:22 -0000 Thank you Jonathan for this clear description of the issues and their = history. I wonder if there's a fourth one - privacy.=20 Rosenworcel's talk = https://docs.fcc.gov/public/attachments/DOC-397257A1.pdf also points out = that ISPs might want to monetize our traffic patterns and location data. = (This is less of an issue in the EU, but the US remains a Wild West in = this regard.)=20 I am hopeful that the FCC will include this in their NPRM (which must be = available by now but I haven't looked...) - Rich Brown > On Sep 29, 2023, at 12:54 AM, Jonathan Morton via Rpm = wrote: >=20 >> On 29 Sep, 2023, at 1:19 am, David Lang via Bloat = wrote: >>=20 >> 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) >>=20 >> 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. >=20 > I think there were three more-or-less separate concerns which have, = over time, fallen under the same umbrella: >=20 >=20 > 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. >=20 > 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. >=20 >=20 > 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. >=20 > 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. >=20 > 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. >=20 >=20 > 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. >=20 > **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. >=20 > 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. >=20 >=20 > 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. >=20 > - Jonathan Morton >=20 > _______________________________________________ > Rpm mailing list > Rpm@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/rpm