From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 ADB163B29E for ; Mon, 25 Mar 2019 04:46:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1553503608; bh=FswYzzEkS2213g8c3fD3v+dZULZfnh6ATw7J8HY9n0A=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=k2fLBh45ZhLrMjhNq49Gph0dj0Za4a5wIDNcB+InRxLWXr1Jna0TJOmod4vH0dLp2 X0KoOo0vy5QCCoMGPNCrNRjU54vCZRbddCNt5IPsM+cQLGt+KhmITPKgK+FCCaBv93 w7wD9aWmOsvOW/W/c+oZzvxFrOUYpQ5FUdMUt9Ok= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.11.12.47] ([134.76.241.253]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lq9oW-1gUaeO1fjE-00dleM; Mon, 25 Mar 2019 09:46:48 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sebastian Moeller In-Reply-To: Date: Mon, 25 Mar 2019 09:46:46 +0100 Cc: ecn-sane@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <3E9C6E74-E335-472B-8745-6020F7CDBA01@gmx.de> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3445.9.1) X-Provags-ID: V03:K1:ecTn+ebhyG8JXCQlXb5vq3wAZ8g7knr39EAgsghu9yvjl34uZh8 9C2AT23isVWS99The3R9fAQUMW+oea3H+EPy2M4YwJ/9OxXs69MGN2JwhMP0SUZy6uNTCXi z73WBV6paINTjtzWHrKgYtqZBoBOZIISBU5mAZEs97XV8WI73yNKjJ/s6TW/kcNTaxzF1g6 wAsLHMjSJ6VVomXNbKqCw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:7YHWCSFwYNQ=:NRdooJ78ZJGpz+kyEtVsOy rSmamaXU2KXeuFR2FWxtChwrP+eu8u4cH9KmI/yGWuiAPsjGS+3CaNBvoC/uQByRpwgO2y9no 7R4w6jth/cfSL4YTRLA4IcxbHyNuF+XqtC58jOrU9RWtyPIB+ETzo7jdttYx3xeShdgAEB8Zz tlyHPE5SPkTuRDRpJchwzHcz6gyv7C5Rw8mX8L7Q4bc/GvyapdLsrhEE9H93eorNQ0L+rpfgB 0SMaGo4pxXhtzrCXmdxMJu5Hf7oov05xOcVyIp97HqzvC2GGj80/kAFsb1M7a1ctfeD9WJceD 05k/BKSEGFZF/X8HIPgNxeIr4U+F/j6qHJIpccnwOK2GFATyIYbKAOVDm3jT0OKOSTMa7e71j hGu6cIdKev8JO2iYhixMKtYsT+vikO+8tekoox0zIVqa1KffFeHMZ7rqu5LEYtbpOV21cB8dL OdWkCkyEzbRbVjZTsCG9nYn9pwiv1jYrkbxJxXdJAG8ypqYmayK7M8TabjwRt+VyQe97g0YvU V76UyW3FgGNoWqzdGkEjU0Bx1ZT5GHEfGQyF8W5Hlj3zNDK22DBbCRr6Bo3x3uOlpbroeavhj OtYqzHweUOBoOP8ssG0119vwxfir0DO9YpFNd5OlkV4r14YhAkU4CZ/WUk7z4TDETHHrcxWdf rAF2Cf65VgVWoQhNiGRIiUbbeC4bYYiSfZb3iAoofBbGSTBk3EN1skgyvL4kFOdeS8egnqfpE KmXDvjCf5pWl1lr7pRAMpr/EQMeso3hthLdjFwE6oMDlDDv0lE8tlXT7bc3qj0Dn5D2CAGRja HNdfs7XSli3QJpxxzK19RCjLKfHIo86hOp9hi7ibIP8c/FoDHlabDjacs8tTIEQPOoJggn663 JvufNvtL1rpuClIXgBRhsUWj1oVfQ+579L41vuf+kVloTJ7e1SFgFgUvpHiUncZ90bC2Alhwb y7dr//dhDDQ== 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 08:46:51 -0000 Hi Mikael, > On Mar 25, 2019, at 08:16, Mikael Abrahamsson = wrote: >=20 > On Sun, 24 Mar 2019, Sebastian Moeller wrote: >=20 >> =46rom 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 >=20 > 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? I do not claim to speak for people on this list, but really just = for myself. >=20 > 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? Out of my area of expertise and interests, sorry. >=20 > 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? So, I have mostly given up on ISPs in this matter, there simply = seems to be no economic incentive I can see for ISPs to spend any money = to improve latency under load behavior of the typical choke points = (access links, aggregation network, transit/peering connections). IMHO = even the very company friendly LLLLS project does not really offer any = noticeable incentives for ISPs to change, that is short of the = ill-defined reordering tolerance there seems nothing in it that directly = might affect an ISP's bottom line. I say ill-defined, as RACK does not = seem to give the re-ordering resistance promises that the link-layer = people would need (I would expect a minimum re-odering time independent = of RTT for this to be useful for both sides). And I have seen how badly this line of reasoning played out with = docsis 3.1's pie ... To recap, DOCSIS 3.1 rejected fq for a single queue = aqm due to keeping CPE cost down to not hinder deployment at scale, but = now DOCSIS3.1 is still not rolled-out at scale, and CPE's often sport = dual-core intel atoms well capable of shaping at the 50-100 Mbps uplink = speeds that ISPs offer (heck these should have enough punch to also run = fq-AQM on the up to 1Gbps downlink of modern docsis-3.1 plans). In other = words I fail to see how this line of reasoning was valid the last time = around and I fail to see how this is going to play out differently this = time around. I do see an opportunity for ISPs to offer "gamer-ready" low = latency router-modems that do all fancy AQM on the CPE side, as a = special item at a extra cost this might actually work economically... = Keep the core network as latency agnostic as it is now, but sell latency = optimized AQM to interested customers, and then pass the cost for the = required hardware to perform this shaping to the same customer that will = profit from it. That at least looks like something that ISP might earn = something from and that will make customers happy (aka win-win). >=20 > 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? So I applaud adding at least a reasonably competent single queue = AQM to ISP gear, but from my vantage point this will not magically make = everything snappy and well for latency conscious end-users and hence = will not replace competent AQM at the client side except that is might = serve as a "backstop" to improve the worst case latency-under-load = increase (even though LLLLS's worst case of 250ms is not that = impressive). >=20 > Again, FQ superior, but what what good is it if it's not being used? Good point, but I want to avoid that something like LLLLS with = the proposed idea of a heuristic how to detect RFC-compliant ECN markig = AQMs will destroy the well-tuned latency-under-load performance of the = ingress shaper at my home that uses fq and conpetent AQM to keep latency = at bay even at saturating loads. Again, I do not want a half-arsed, = optimised for low-cost (let's face it this all boils down to money and = who pays), solution like LLLLS to screw things up. I note that this = hinges up the leaky classifier proposed and is not an argument against = LLLLS and its goals. >=20 > We need to have this discussion and come up with a joint understanding = of the world, otherwise we're never going to get anywhere. Fair enough. I note again, I am from outside the field and just = represent an opinionated end-point and I approach the issue from that = vantage point, please do not expect me to reason for ISPs where I have = no reliable insight in the economic or engineering challenges. Best Regards Sebastian >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se