From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lang.hm (unknown [66.167.227.145]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id F063B3B29D; Thu, 28 Sep 2023 18:25:42 -0400 (EDT) Received: from dlang-mobile (unknown [10.2.2.69]) by mail.lang.hm (Postfix) with ESMTP id 284AD1AF218; Thu, 28 Sep 2023 15:25:42 -0700 (PDT) Date: Thu, 28 Sep 2023 15:25:42 -0700 (PDT) From: David Lang To: dan cc: Dave Taht , Rpm , libreqos , Jamal Hadi Salim , Dave Taht via Starlink , bloat In-Reply-To: Message-ID: <8625q6o8-rsrn-ns67-5so8-qn7ss72s9qs8@ynat.uz> References: MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="===============2536559376681491467==" Subject: Re: [Rpm] [Bloat] [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: Thu, 28 Sep 2023 22:25:43 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============2536559376681491467== Content-Type: text/plain; format=flowed; charset=US-ASCII On Thu, 28 Sep 2023, dan via Bloat wrote: > Common Carriers or rather, carrier class services for 'internet', should be > completely neutral. Packets are packets. However, I think it's important > to carve out methods to have dedicated links for real time flows at the > carrier level. I don't know what that model looks like exactly, but being > too stubborn about purist NN principals could really hurt VoIP services if > there aren't methods to handle that. I guess I really am describing > 'internet fast lanes' for certain classes of services that we deem > important enough as a whole. not individual ISPs deciding, but rather 'the > will of the people' saying VoIP is more important than netflix, you can > carve out dedicated capacity for that. the fq_codel/cake approach violates the strictest interpretation of 'packets are packets' but diffentiates between well behaved and short flows and ill-behaved bulk flows. That is content and destination neutral, but prioritizing for a fair experience to all. In theory, 'fast lanes' and QoS priorizations can make VoIP and similar work, in practice there are too many different apps behaving in too many different ways for anyone to fix the problem with static rules and prioritization. make sure that you don't through out cake-like content neutral improvements in your quest for 'a packet is a packet' (and remember, some of the people interpreting/implementing your rules will have it in their interest to make it as painful for users as possible to be able to blame you for the problem, so you can't count on 'reasonable interpretation' of the rules) David Lang --===============2536559376681491467== Content-Type: text/plain; CHARSET=utf-8 Content-Transfer-Encoding: BASE64 Content-ID: <71711n29-p675-8rr3-o2p6-491r998rrn20@ynat.uz> Content-Description: Content-Disposition: INLINE X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQmxvYXQgbWFp bGluZyBsaXN0CkJsb2F0QGxpc3RzLmJ1ZmZlcmJsb2F0Lm5ldApodHRwczovL2xpc3RzLmJ1ZmZl cmJsb2F0Lm5ldC9saXN0aW5mby9ibG9hdAo= --===============2536559376681491467==--