From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 7DD4D3B29E for ; Mon, 25 Mar 2019 03:16:45 -0400 (EDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E07DDAF; Mon, 25 Mar 2019 08:16:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1553498203; bh=6klhpkWtKOyp1G9dfFwkng8EbrTEZ8pWBE7mGPNZqRE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=2jswFBxVFJOgREd93wELXVXdYD/8KVyB20OPi3NCF6xcjSelpoU97r/oa58P2KNrj bYZJJxwh7/ysf5LwwCXLq3iUZXAdTZkGbHiFBWrnMgwc4C4VOcYwtUHMY5Lndzm5HA i9uS0bfHg6mI1kL8iomfmrKZxJKtyO7XAvdzbAj0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DC1889F; Mon, 25 Mar 2019 08:16:43 +0100 (CET) Date: Mon, 25 Mar 2019 08:16:43 +0100 (CET) From: Mikael Abrahamsson To: Sebastian Moeller cc: ecn-sane@lists.bufferbloat.net In-Reply-To: <3E9C6E74-E335-472B-8745-6020F7CDBA01@gmx.de> Message-ID: References: <3E9C6E74-E335-472B-8745-6020F7CDBA01@gmx.de> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: [Ecn-sane] robustness against attack? X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 07:16:45 -0000 On Sun, 24 Mar 2019, Sebastian Moeller wrote: > From my layman's perspective this is the the killer argument against the > dualQ approach and for fair-queueing, IMHO only fq will be able to Do people on this email list think we're trying to trick you when we're saying that FQ won't be available anytime soon on a lot of platforms that need this kind of AQM? Since there is always demand for implementations, can we get an ASIC/NPU implementation of FQ_CODEL done by someone who claims it's no problem? Personally I believe we need both. FQ is obviously superior to anything else most of the time, but FQ is not making itself into the kind of devices it needs to get into for the bufferbloat situation to improve, so now what? Claiming to have a superior solution that is too expensive to go into relevant devices, is that proposal still relevant as an alternative to a different solution that actually is making itself into silicon? Again, FQ superior, but what what good is it if it's not being used? We need to have this discussion and come up with a joint understanding of the world, otherwise we're never going to get anywhere. -- Mikael Abrahamsson email: swmike@swm.pp.se