From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B1D6E3B29E for ; Sun, 19 Nov 2017 13:33:07 -0500 (EST) Received: from nemesis.taht.net (c-24-6-113-161.hsd1.ca.comcast.net [24.6.113.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id B36CA21474; Sun, 19 Nov 2017 18:33:05 +0000 (UTC) From: Dave Taht To: Matthias Tafelmeier Cc: Bob Briscoe , ken@cs.cornell.edu, bloat@lists.bufferbloat.net References: <4d54f24f-ce83-34a0-41f3-9f728420d548@gmx.net> <87shdr0vt6.fsf@nemesis.taht.net> <79f4d92c-74f4-8cd0-9d38-e51a668cb9b6@gmx.net> <796aa11e-9e35-cf34-e456-6ae98d1875d6@bobbriscoe.net> <87fu9f72za.fsf@nemesis.taht.net> Date: Sun, 19 Nov 2017 10:33:02 -0800 In-Reply-To: (Matthias Tafelmeier's message of "Sat, 18 Nov 2017 16:38:52 +0100") Message-ID: <87a7zirue9.fsf@nemesis.taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Bloat] DETNET X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 18:33:07 -0000 Matthias Tafelmeier writes: > On 11/15/2017 08:31 PM, Dave Taht wrote: > > Nonetheless, it's important to have a debate about where to go to next. > Personally I don't think fq_CoDel alone has legs to get (that) much better. > > The place where bob and I always disconnect is that I care about > interflow latencies generally more than queuing latencies and prefer to > have strong incentives for non-queue building flows in the first > place. This results in solid latencies of 1/flows at your bandwidth. At > 100Mbit, a single 1500 byte packet takes 130us to deliver, gbit, 13us, > 10Gbit, 1.3us. > > A not necessarily informed enough question to that: couldn't this marking based > virtual queueuing get extended to a per flow mechanism if the marking loop was > implemented in an efficient way? Bob's mechanism splits into 2 queues based on the presence of ecn in the header. It is certainly possible to do fq with more queues within their concept. :) I've tossed fq_codel onto their groups' demo. Which, if you toss any but their kind of traffic through it, seemed to perform pretty good, and even with... well, I'd like to see some long RTT tests of their stuff vs fq_codel. At the moment, I'm heads down on trying to get sch_cake ( https://www.bufferbloat.net/projects/codel/wiki/CakeTechnical/ ), maybe even the "cobalt" branch which has a codel/blue hybrid in it, upstream. Mellonox is making available a toolkit for some of their boards, I've been meaning to take a look at it. ENOTIME. On the high end, ethernet hardware is already doing the 5 tuple hash needed for good FQ for us (this is used for sch_fq, fq_codel, and even more importantly RSS steering), but cake uses a a set associative hash and some other tricks that would be best also to push into hardware. I'd love (or rather, an ISP would love) to be able to run 10k+ good shapers in hardware. ... At some point next year I'll take a look at detnet. Maybe.