From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 8A5213CB40 for ; Mon, 18 Dec 2023 16:55:54 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1702936545; x=1703541345; i=moeller0@gmx.de; bh=4mauPWpzRMiOU0M2eVO9k7sHhzKursZNvyv5HlNdSCA=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References: To; b=NAKZNqXwaxuMBfxQj3DTcnM+x5BikGeQdXsraA8XfMr71a9ncZkCYBlloLW3Cs0i SinQg2nqmBOg1nHrBPkGXCAJPw8HIF1JXlEY3dvem+qedCbRJJFhSp+fKzczR3Tqf oS+QL8ChSZmKNOqqthd5pU8Z7eopuXhAN+shS5EnmdNQeO+TypyYeECxrCpE762Lv lZ2k1wIOqko2CRAoFFr00881eCkY4NWw/r+KmZPToT3NKACkwHD9dgrW0BqWP6ymI KfJb1Hz4NRQO9zvdAnpXjzdQ2vF/N679wkaGjg6qDDQB99lq8OetgjRy2N7Fh4ytn CHNd5iraemFOcmOvfQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([77.0.220.75]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MCbEp-1rOvxa2RJj-009db3; Mon, 18 Dec 2023 22:55:45 +0100 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: <4A72F53430994BA488E2BD4BCE7741FB@SRA6> Date: Mon, 18 Dec 2023 22:55:44 +0100 Cc: =?utf-8?Q?Network_Neutrality_is_back!_Let=C4=ABs_make_the_technical_as?= =?utf-8?Q?pects_heard_this_time!?= , Ronan Pigott Content-Transfer-Encoding: quoted-printable Message-Id: References: <0256BC1C-06CF-4E12-9C88-E42590CBBFB9@comcast.com> <512AB204-6A66-47F6-A789-DB2EC403F639@gmx.de> <4A72F53430994BA488E2BD4BCE7741FB@SRA6> To: Dick Roy X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Provags-ID: V03:K1:mEmlSACKat5GF6DfRP3Xqz/3JKr5vDTNxW+lNvrxlvnF/0Ix8R4 iQtAO6Q+kjSP0CGoqvAwE6HrmJTXEWKYeUcclppi2GdW9+mlND2E0RDNQ7ZSRuLxm1lz9ru EeZ9ODbnNGfRBfyBM9ZV2PjbPPgLXYe60OcLRrDOhgy7SC92+FqYWBkVvUynPaNR6jHQIJc C0KhTqU9deiBh7qAQjBcA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:gcyxmF+aqyg=;1AisnoEC3FjjfDaTzVDphRZEcPK HZUIukedf1NLmDnczeacvaYae8JfTWT5p6/N47iTZR9ze5YovBFZTmI7fAw9YPr91BvGCLoDN O9YPbFnQQPnSADX+PGwu1y2lqD3xAsjsaK7Q3P15sfjVkXZra8OGzgKY1Y67CiitZ+UElSwuL 95d5U6KHxlvXQ3OIQKYtx0lv2VayDKfbeGV0Ounrf1kQvJxRkkPGNpIvHaxjHeLrFoyUf//eJ oOIN7hHexR2EZdjdvpwXa5D61ff73XezAzGzR6prNvYxAtb4PQvqqaE+5dcMft2fpCdQdPxkk 3KNyDj3eCGcdm8h85muBwxQ/jHC+h4fs6sLCNg5c2SgJu7bsl6DFsKCRAejs4dtE7LUsyomtj Yj3CjujDnCMc2rDLhsgtrOCvbfEWj241tYG/hz5aXfQBwQKMJFfeMkG4W7rZVbnH5Txt5xxGo gWL3I57Q7npPOJYYstnvifEmQoOteCU84A/RPIjoWslXHZ19+GvvcprdvVWRE7M/ZR0ZtJ6SB 8JtIvl6axy17xB6AJ12XDet1Uh9fWzKy2z4ZDjKQt6moX84UuaWx1FEN62clZy7A7Uypb/Vgw R+QIqDL82kI59EhSCQ/VAunfM++s3CGhrEUoSOxFXWN/gq1iDk6tKounzFEfvVhvCB7UgAV9I MwPMk8gvlb9IE3SD+AU3dOf6oqRI3uYPqSMqPC2EoYkv17i7Tsu96mGEp+YwUf7igBcxuQXPJ DqsJsq1Zim/0LZeEBuPtpY+cKhWILse/cQ4EVDCofUepUDrXvOCAZdFYiKQ9QfdAnfm5b0RPW ZSnrWocUi5SjuD4NOiZ5aPd+Efw8xz5qit9hf0SMlg34sO8flcKgrYP1502nC+g7b8EwWyY0q 9GceHjoPrGXp4XPUWyjlzbgBUxzjB863En8gB1VdKd9BVYo3xctn9vXVCc3TOvpQzCf2Ti+er oBUvwA== Subject: Re: [NNagain] Net neutrality and Bufferbloat? X-BeenThere: nnagain@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: =?utf-8?q?Network_Neutrality_is_back!_Let=C2=B4s_make_the_technical_aspects_heard_this_time!?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2023 21:55:54 -0000 Hi Dick, > On Dec 18, 2023, at 21:51, Dick Roy wrote: >=20 > Given that the capacity of a system is in essence a theoretical = maximum (in > this case data rates of a communications sytem), I am not sure what = "scaling > the capacity to the load" means. Oh this was supposed to mean that the EU regulators expect ISPs = to increase their internal capacity if the sustained load of their = customers exceed the given capacity reliably for too long. If an ISP = throttles all streaming due to a transient overload and to allow e.g. = video conference traffic to flow smoother this is acceptable, if the = same ISPs decided to do so ad infinitum to save the cost of removing = bottlenecks from its networks that will be a problem (in theory, how all = of this is handled in practice I can not tell).... But hey I am = extrapolation from EU regulation 2015/2120 : The objective of reasonable traffic management is to contribute to an = efficient use of network resources and to an optimisation of overall = transmission quality responding to the objectively different technical = quality of service requirements of specific categories of traffic, and = thus of the content, applications and services transmitted. Reasonable = traffic management measures applied by providers of internet access = services should be transparent, non-discriminatory and proportionate, = and should not be based on commercial considerations. The requirement = for traffic management measures to be non-discriminatory does not = preclude providers of internet access services from implementing, in = order to optimise the overall transmission quality, traffic management = measures which differentiate between objectively different categories of = traffic. Any such differentiation should, in order to optimise overall = quality and user experience, be permitted only on the basis of = objectively different technical quality of service requirements (for = example, in terms of latency, jitter, packet loss, and bandwidth) of the = specific categories of traffic, and not on the basis of commercial = considerations. Such differentiating measures should be proportionate in = relation to the purpose of overall quality optimisation and should treat = equivalent traffic equally. Such measures should not be maintained for = longer than necessary. > Throttling the load to the capacity I > understand. Yes, I thought it was clever to flip this nomenclature around, = but as you demonstrate "far too clever" ;) Regards Sebastian >=20 > Hmm .... >=20 > RR >=20 > -----Original Message----- > From: Nnagain [mailto:nnagain-bounces@lists.bufferbloat.net] On Behalf = Of > Sebastian Moeller via Nnagain > Sent: Monday, December 18, 2023 7:24 AM > To: Network Neutrality is back! Let=C2=B4s make the technical aspects = heard this > time! > Cc: Sebastian Moeller; Ronan Pigott > Subject: Re: [NNagain] Net neutrality and Bufferbloat? >=20 > Hi Jason, >=20 >=20 > during the Covid19 era, the EU issued clarifications that even = throttling a > complete class like streaming video might be within reasonable network > management. The only stipulations wer this needs to happen only to = allow > arguably more important traffic classes (like work-from home vide > conferences or remote schooling) to proceed with less interferences = and > blind to source and sender. That is using this to play favorites = amongst > streaming services would still be problematic, but down-prioritizing = all > streaming would be acceptable. (Now the assumption is that reasonable > network management will not last for ever and is no replacement for = scaling > the capacity to the load in the intermediate/longer terms). >=20 >=20 >=20 >> On Dec 18, 2023, at 16:10, Livingood, Jason via Nnagain > wrote: >>=20 >>> Misapplied concepts of network neutrality is one of the things that > killed >>> fq codel for DOCSIS 3.1 >>=20 >> I am not so sure this was the case - I think it was just that a = different > AQM was selected. DOCSIS 3.1 includes the DOCSIS-PIE AQM - see > https://www.rfc-editor.org/rfc/rfc8034.html and=20 >>=20 > = https://www.cablelabs.com/blog/how-docsis-3-1-reduces-latency-with-active-= qu > eue-management. I co-wrote a paper about our deployment during COVID = at > https://arxiv.org/pdf/2107.13968.pdf. See also > = https://www.ietf.org/archive/id/draft-livingood-low-latency-deployment-03.= ht > ml. >>=20 >>> Finally, some jurisdictions impose regulations that limit the = ability of >>> networks to provide differentiation of services, in large part this = seems > to >>> be based on the belief that doing so necessarily involves = prioritization > or >>> privileged access to bandwidth, and thus a benefit to one class of > traffic >>> always comes at the expense of another. >>=20 >> Much regulatory/policy discussion still frames networks as making > decisions with scarce bandwidth, rather than abundant bandwidth, and > prioritization in that view is a zero-sum game. But IMO we're no = longer in > the bandwidth-scarcity era but in a bandwidth-abundance era - or at = least in > an era with declining marginal utility of bandwidth as compared to > techniques to improve latency. But I digress. >=20 > Speaking from my side of the pond, over here we still have a > somewhat big divide between those sitting on heaps of capacity and = those > that are still in the painful range <=3D 16 Mbps (16 itself would not = be so > bad, but that class goes down below 1 Mbps links and that is IMHO = painful). >=20 >=20 >>=20 >> To go back to the question of reasonable network management - the key = is > that any technique used must not be application or = destination-specific. So > for example, it cannot be focused on flows to the example.com = destination or > on any flows that are streaming video [1].=20 >=20 > See above, while as long as example.com is not violating the law > this first is also not an option inside the EU regulatory framework, = but the > second already has been under specific limited circumstances. >=20 >=20 >> Anyway - I do not think new AQMs or dual queue low latency networking = is > in conflict with net neutrality.=20 >=20 > I agree that AQMs are pretty safe, and I feel that packet = schedulers > are also fine, even conditional priority schedulers ;) >=20 > Regards > Sebastian >=20 >>=20 >> Jason >>=20 >> [1] Current rules differ between wireless/mobile and fixed last mile > networks; currently the MNOs have a lot more latitude that fixed = networks > but that may be sorted out in the current NPRM. My personal view is = there > should be a unified set of rules of all networks. >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Nnagain mailing list >> Nnagain@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/nnagain >=20 > _______________________________________________ > Nnagain mailing list > Nnagain@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/nnagain >=20