From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id CFDA53BA8E for ; Tue, 14 Nov 2017 15:10:30 -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 54E9E21341; Tue, 14 Nov 2017 20:10:29 +0000 (UTC) From: Dave Taht To: Pete Heist Cc: cake@lists.bufferbloat.net References: Date: Tue, 14 Nov 2017 12:10:26 -0800 In-Reply-To: (Pete Heist's message of "Tue, 14 Nov 2017 10:51:53 +0100") Message-ID: <87vaic8vv1.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: [Cake] Donation X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 20:10:31 -0000 Pete Heist writes: >> On Nov 12, 2017, at 6:00 PM, cake-request@lists.bufferbloat.net wrote: >> >> I sometimes think we should establish an organization, with a board of >> directors, a bank account, etc, but aside >> from grant money, donated computers and computer time, and all the >> massive efforts of all the volunteers, that's most of the donations >> we've ever got, and it would be, at least, 800 bucks to start a >> non-profit, + an accountant to "do right". >> >> Any and all thoughts as to how to do better are welcomed. >> >> We could have a bake sale for cake, to get it mainlined. > > Has there been any thought towards monetizing some portion of the bufferbloat > project to help pay for it? Here are a couple of ideas: I'm going to skip commenting in the hope that others chime in first. > By the way, what or how much is needed to get Cake mainlined? I'd like us to give it a go when net-next reopens in two weeks, we'd then have 6 weeks or so to get it right. We need: * Someone to do the heavy lifting. Which I suspect would be me. * Someones with various hardware platforms that current kernels can be run on. qemu? * I'd like to see the ack filtering work get tested on lede at low bandwidths on dsl especially. * A whole lotta tests at various RTTs Blockers: * Ripping out all the backward compatability cruft for submission to mainline and following netdev formatting conventions for comments and indentation. I'd like any new features in the backport to get backported, though (sigh), as lede looks to be shipping a 4.9 based kernel. * tc-cake man page needs to be updated. * tc-adv related code updated to latest iproute2 * There is some work going on here to add ack filtering to cake, which looks VERY promising: https://github.com/dtaht/sch_cake/pull/63 I'm going to add something like this to netem also. It may be that merely leveraging the hash would be enough in cake's case. * Testing against the net-next kernel on x86, x86_64, arm, mips, and aarch architectures. (I just got bit by not testing 32 bit arches, sigh) Non-Blockers: * I don't believe in cobalt, or rather, I won't believe in it until we have data at many RTTs. That said, what I'd propose would be a monolithic cobalt.h file rather than codel5.h. The netns stuff will make simulating RTTs and bandwidths much easier.... * I think the fq_codel batch drop facility is better than what cake uses in case of floods. Partially due to the need to handle backports the mechanism fq_codel uses is hard to use - but going mainline we could add this. * The autorate_ingress code should be marked experimental. I keep hoping it can be improved by better looking for "smoothness" inbound, but algorithms escape me. This doesn't bother me much, as tcp continues to be improved over the past 50 years, perhaps we can find ways to improve this with more users. * It is possible to tune the quantum and peeling functions to not peel to the extent they do. Particularly there is usually no need (aside from wanting accurate statistics) to peel below 1500 bytes (except perhaps with the new ack filter mode). We experimented a lot with this in the early days but could never come to a resolution. * I don't have any use for precidence mode and would like to remove it.