From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (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 6C3173B29E for ; Mon, 25 Mar 2019 03:55:07 -0400 (EDT) Received: by mail-qk1-x742.google.com with SMTP id n68so4759181qka.1 for ; Mon, 25 Mar 2019 00:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=I7FBDFjUeJyAJyIcwQbNwKswPuDiM4y/kltPOSFap5c=; b=CI61ZDTmbPtAM3XC+dyOdMkrPysj56+mk0LooYH2nv1ouMn/Y0rp+MBvIMl9uaL2jL J+nXIV3gSCtw7rAxF4u7Po8x626K41rKkpIYCVTTIx1cPeSa9S+pDTaaYgzSGNh5rjmK PwvtiCITKaYfxGRMoX5wQtMf+RkEwb3jiBJEjjcWqL5LKsD931TSjmOJJNUj2n4U+0gG LtOpiNmcD3VomxwM2TnrD1Tjf2ic53bl3it9lXPnnZuWOW/LshTp1A8S5IE5Eo+CdEx/ ltXUznBJdqjg8hB1r4vcxEoDWl3Ev2bES5vIgnWa79cn9v6V92VmfP9OkMaFBh9lvUuS 4Xyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=I7FBDFjUeJyAJyIcwQbNwKswPuDiM4y/kltPOSFap5c=; b=IFB0iO3o3P7aMS0UFjencOb1alGbrRSr68+2otiEl1irX5pOV4tovlHsbQhFZJidPT P7T4CisXa6S3xuVTq0Pijw5/+gzBsTvGTJHRHLeX5+rqlyeAajWR0/uN7jnCMzF8lgpF icxUFDGd6SFsVGW2WXCkfgLKJ8Js7b6zEJtWr+/dyYRkqqLR2hg5Sk2pDhxFvf1kaJYR OutGNQs4b4bSH+nfWGpKqFjWGbm8TLKSlISZdIB7g+xQ9dl2h1qfpobzxteGaSRGhmBl GPaBYXIFLvV21gJnnzAWnUGNXqAusG7GoSpkFwJfCiPdA2oi8ixV9UPP6fQyAgKF/7xM p4Zg== X-Gm-Message-State: APjAAAUh/VzSBK5ZeSXcxzJntSH0xcpsShGKJWIa2a++PleCFB6LszQl ORFz/jGTxEyGKIxrXAsaepFQDyN9oFbNC3T5Iaw= X-Google-Smtp-Source: APXvYqwp8BVONbWWpIjxfm2dW7lGdMN5DbgQN4n4kldBIBRvxd5UYULDQQ3Elma/MUJF4LzUZbsei1lDq+9VeUPamR0= X-Received: by 2002:a37:9c46:: with SMTP id f67mr16561428qke.65.1553500506940; Mon, 25 Mar 2019 00:55:06 -0700 (PDT) MIME-Version: 1.0 References: <3E9C6E74-E335-472B-8745-6020F7CDBA01@gmx.de> In-Reply-To: From: Dave Taht Date: Mon, 25 Mar 2019 08:54:55 +0100 Message-ID: To: Mikael Abrahamsson Cc: Sebastian Moeller , ecn-sane@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [Ecn-sane] FQ in the core 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:55:07 -0000 I don't really have time to debate this today. Since you forked this conversation back to FQ I need to state a few things. 1) SCE is (we think) compatible with existing single queue AQMs. CE should not be exerted in this case, just drop. Note that this is also what L4S wants to do with the "normal" queue (I refuse to call it classic). 2) SCE is optional. A transport that has a more agressive behavior, like dctcp, should fall back to being tcp-friendly if it sees no SCE marks and only CE or drop. 3) At 100Gbit speeds some form of multi-queue oft seems needed. (and this is in part why folk want to relax ordering requirements). So some form of multiple queuing is generally the case. At the higher speeds, DC's usually overprovision anyway. 4) The biggest cpu overhead for any of this stuff is per-tenant (in the dc) or per customer shaping. This benefits a lot from a hardware assist. (see senic). I've done quite a bit of DC work in the past 2 years (rather than home routers), and have had a hard look at the underlying substrates for a few multi-tenant implementations.... 4) "dualq" hasn't tried to address the fact that most 10Gbit and higher cards have 8 or more hardware queues in the first place. 5) Companies like preseem are shipping transparent bridges that do fq_codel/cake on customer traffic. I've long been in periodic negotions with makers of "big iron" like, for example, the new 128 core huwei box and others I cannot talk about at the moment, to get so far as an existence proof. So I'd like to kill the meme that SCE requires FQ, at least, for now, until after we do more tests. As for FQ everywhere, well, I'd like that, but it's not needed in devices that already have sufficient multiplexing. On Mon, Mar 25, 2019 at 8:16 AM Mikael Abrahamsson wrote= : > > On Sun, 24 Mar 2019, Sebastian Moeller wrote: > > > From my layman's perspective this is the the killer argument against th= e > > 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 > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740