From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 D1E0C3B29E for ; Mon, 25 Mar 2019 05:23:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1553505793; bh=ue/1kKjskT+EcOjauSTcMpX2t7somogAlaKVuZ97ssU=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=PDqhak2FpiQCavNpaFnC8e0Py4aNdtHert8zNyWC9X/ZcORC1uGBM3bQU5YyDEEjC z+I8oQZs+tcWQuQrdxY1SUGdt8AQapKKF232EbEsQKkv8nGM/9DnSShY8vjB+ZaUqe gFEmgy4EcN21J6eywDz42dohcb5k+g0i1O3TnXDY= 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 0MMTEM-1h3Mx43mIQ-008G8z; Mon, 25 Mar 2019 10:23:12 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sebastian Moeller In-Reply-To: Date: Mon, 25 Mar 2019 10:23:11 +0100 Cc: Mikael Abrahamsson , ecn-sane@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <3DD337F0-6D06-441C-9FE6-43F1D887F796@gmx.de> References: <3E9C6E74-E335-472B-8745-6020F7CDBA01@gmx.de> To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3445.9.1) X-Provags-ID: V03:K1:h6sqhHgXjVT23wpMKVWV9sE3j+aa5QZ0/rVKXtW3s17ryqotLM/ 3rOb/mk4JhstKNg4gHoSRgdbM9CKzt+vdWFjIJhmE78tLxjfM0emUVDmgYUqP9cz8/wf/JI ekAg8zMn8hVEGEZS9GOnggX4TClZfmcE5l68fifiWvEW2HVAM3xE4sTGOx2bBCJXe07iHEN HxUDu+me3pac3m01R0g0Q== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:kwZXpCXReY0=:BgZ/HFUbzRWmb1dBf25Vv5 CzPxgQGMfTWWbk2t11N4iD2jUUUPdGLqdugJmGTr1ANMsdqRgYsII2y0OI45iv8TshbU0ZGDQ NlB7kZ4qiRQ4b91wMsMLMlbc2SufdSSnlxUBpyB+gICUuvKUbwRz2en0AJkohxQx7eV5uwFbf 49nBsFgErvJqj1Hmwxm8Ga6kms+oEVdbAN3bo1k80xUFBJ217Dx61QYYNw7mlzWXIQ6dwm2Bn qcIPBBTCuJpVS7z4E/hOhy7VimToTXg53aJBybK4LIH8Asj0b+Bq0PzFtXWn5kZIlT4bgnOg/ V3DTXPMXr03RkNlOvd0knh1qgU1x5Opi802Dj7zyfAilk0bgZOl4ytNTU/bJGDB4Slmva2xNy 0PNBEhqrhPaSxvsDcSg2vhCrUZpYZZs0tyUCIhYelZkXSLCiB2OTZHULuHLUjLxPK69wDdzcS oAbO9SvvD8/CkkT2g5e0dVZR/sgxfmtKWkjO4eLcWhwHK9nnWLr06+SFVTLKo0t4Gw4/tBFIw q88/OSyc9BxBdOtobUm8oFaF2tqg6J17nEZ1dCKK+FTUGSO+egq8jo/LhwFjXFCEF7kuW8LNo lQuETQxE6HEq479DXkhD7GdGwHCGWoCRN5tURywjKvzKNhMuOxs92PdS8OdjG0qzL80tpWxDn iJtXTFHsblA1HdIIckkUwU1MtTh+iwuH9y1PpiV4xWOAfsak5zmAiibZLTQul1BONtjVEfb2A 5IF24LPrrfwzmasmShM4tx89FDQTNEFINs9Wez8kXn8lQIqYt2PGWgOQ5G3pwH9C/PTvu1VOh KHKnCejZgcAG+F0fASCbgAuiMZvLe9d+gvmDpeIdjR0mYA5RKZazcM4H5nf7Dwx30G9P7mlIK KUIKvgnORsOnr3MR96cyu8Xd5Tt7/erUxFm2OGliACsy7XAUj/LtZR5M1C6wAGkEKoeH2W1p6 ow0YMROqP1Q== Subject: Re: [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 09:23:15 -0000 Hi Dave, > On Mar 25, 2019, at 08:54, Dave Taht wrote: >=20 > I don't really have time to debate this today. By all means put this on the back-burner until tomorrow.... >=20 > Since you forked this conversation back to FQ I need to state a few = things. >=20 > 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). Call it the internet-queue then? >=20 > 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. And this is where LLLLS faces challenges as it needs to use = heuristics to throttle back to tcp-friendliness, which wil also be = intersting once LLLLS will start to try to follow BBR in potentially = ignoring dropped packets... >=20 > 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. Okay, that should allow to calculate a proposal for a minimum = re-ordering window? Because I believe that RACK should allow for a = minimum re-ordering window to actually allow transit ARQ to work = efficiently without needing many stalls. > 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.... Can you actually talk about this? >=20 > 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. >=20 > 5) Companies like preseem are shipping transparent bridges that do > fq_codel/cake on customer traffic. >=20 > 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. >=20 > So I'd like to kill the meme that SCE requires FQ, at least, for now, > until after we do more tests. My point here is not that fq is required, but rather that single = queue AQMs seem easier to abuse as they assume full cooperation by all = participating flows. >=20 > As for FQ everywhere, well, I'd like that, but it's not needed in > devices that already have sufficient multiplexing. That would be aggregation networks and transit/peering points, = no? That still leaves the edge... Again, please ignore until the IETF meeting is over. Best Regards Sebastian >=20 >=20 >=20 >=20 >=20 > On Mon, Mar 25, 2019 at 8:16 AM 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? >>=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? >>=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? >>=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? >>=20 >> Again, FQ superior, but what what good is it if it's not being used? >>=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. >>=20 >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se >> _______________________________________________ >> Ecn-sane mailing list >> Ecn-sane@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/ecn-sane >=20 >=20 >=20 > --=20 >=20 > Dave T=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-205-9740