From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 67F2C3B2A4 for ; Mon, 25 Mar 2019 11:23:36 -0400 (EDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0BABEAF; Mon, 25 Mar 2019 16:23:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1553527415; bh=cWIyp8q4oOT2SuIw6HrfzkntF8JtNZ/m/AF3EWRn41o=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Jz5tJgr5iquLxvzo5QPTMhxgE6tiM4G2EkgMSgBDi1a9JlsQcNfQFV7SunnLpeJ4E kIPpfwYbk9bgj9iq3Xf8p7mN74+PbL2ot5379kmPWX0M6KmQUu0sRl13O9jK4HRuf2 zagEEi+el5PQlJ0ceVEUaA2bVYbWeqCzquLmHm74= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 098FF9F; Mon, 25 Mar 2019 16:23:35 +0100 (CET) Date: Mon, 25 Mar 2019 16:23:35 +0100 (CET) From: Mikael Abrahamsson To: Jonathan Morton cc: ecn-sane@lists.bufferbloat.net In-Reply-To: <907D3152-4AD5-4551-AA6A-46FF9CA567DE@gmail.com> Message-ID: References: <3E9C6E74-E335-472B-8745-6020F7CDBA01@gmx.de> <907D3152-4AD5-4551-AA6A-46FF9CA567DE@gmail.com> 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 15:23:36 -0000 On Mon, 25 Mar 2019, Jonathan Morton wrote: >> On 25 Mar, 2019, at 8:16 am, Mikael Abrahamsson wrote: >> >> 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? > > Well, I don't. I recognise that most high-capacity links will end up > with single-queue AQM, because that's what's already out there in > hardware (though it's rarely turned on so far). I'm still keen to see > good FQ used where feasible, and in ways that make local sense. Ok, so can we please drop the "FQ" part of the conversation for the next months, and argue on few-queue systems and how to come up with things that are friendly to implement in hardware? Just to state again what I have said several times: Devices such as high speed residential gateways, BNGs, CMTSs etc, they will not get FQ anytime in the next 5-10 years (or someone will have to prove me wrong). So please stop arguing about the wonderfulness of FQ. Yes, fine, it's great, but it's also not applicable to lots of places where we need to de-bloat. -- Mikael Abrahamsson email: swmike@swm.pp.se