From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (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 7614A3B2A4 for ; Fri, 23 Dec 2016 12:01:37 -0500 (EST) Received: by mail-qt0-x244.google.com with SMTP id p16so11673131qta.1 for ; Fri, 23 Dec 2016 09:01:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sd35AYnOF+rZHyyKYmZ/U8FoGaM5ieShw3Sx1Y/skvs=; b=b/h9dJIzwHxj96JlE62tMcI3NJ7fRyRKN3TYlyLWsJUWBikCC1qEO6oTV3weeoE10o Hgq8yj3QateXxc35eKVD69oYdhVJ2+pLz9Oi0eCtsvvBLiN21U9T4Lydjdwtv/mhuIck XVB6Rc78ZR/T+tp4LQb34xXEh4FncmQJzxvrVDL8m179mkX8nvWSGz60fp+J+sxyf/1R mCHotrK72ewHfyVKyLtjxY+Zg6kUIgkoO6Zpg3RrsYEUCKH8ApVXswHgsmEUeh6LL7ex o/ZOp6Pf0Ta0Hkys/fgcIdKlEP3Hubs+6bDjRdPnula7yWuAr+gbLMyu5tjK2vBRFWuN Y3pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sd35AYnOF+rZHyyKYmZ/U8FoGaM5ieShw3Sx1Y/skvs=; b=qV4h5WfNJMnvLjn6yeC1nG7T9VNrOv3y+wxEfiF+3lQpyIIvsSIL2afq0BwpCzgoF9 qtIUZoIQzaK+Aa1bL7WvkGdD19BdxvzE5YyyGwnOzntIvlxR4K20cze8LQRUEoW2Ty3P S4FWNYD3MGJjlY/kDLk48/RQU4slZq/Rg376QL/LIKnTGk+GdjafdG0SHd+MTPGU/t8C s82taFCyn/diq19/D1mS14MkTIJQ82VZAbqa3mjUy73UzIKby6xg5DE1wjEHOfpOaNj0 K/VHRbixqaxOoXDuDjlnykKyJABvH+S+gwRySUGdgxo4NnEFROaj7qPbR/enRmuboAG2 kQTA== X-Gm-Message-State: AIkVDXKar9r1XJxOUWHw8OLCN7mXPUJLpT68kfSi3GPHfh/bsMIx7tLXihoZgOFqwOFFq5AbvMjTcQp4IYVyvQ== X-Received: by 10.200.34.73 with SMTP id p9mr17589804qtp.25.1482512497056; Fri, 23 Dec 2016 09:01:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.152.197 with HTTP; Fri, 23 Dec 2016 09:01:36 -0800 (PST) In-Reply-To: References: <20161222174349.5bd5dffd@xeon-e3> <9A8ACB3B-8411-414E-B2C3-ABE2C276B351@gmail.com> <606D54F6-59FB-49D6-A969-F26434EF9292@gmx.de> <273D5631-610F-4BD7-BBC9-151A1E8F42BD@gmail.com> From: Dave Taht Date: Fri, 23 Dec 2016 09:01:36 -0800 Message-ID: To: Sebastian Moeller Cc: Jonathan Morton , cake@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Subject: Re: [Cake] upstreaming cake in 2017? 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: Fri, 23 Dec 2016 17:01:37 -0000 I have largely been focused on make-wifi-fast until the last week, only doing a code review on cake over the last few days and submitting a few patches thus far. I have sometimes been frustrated enough on the squash/wash issue to want to fork cake to "just do it", because RFC compliance actually mandates that the traffic be re-marked appropriately upon transiting a domain, and seeing CS1 enter my network from comcast really messes up if it is passed directly through to wifi. It is far, far better to squash on ingress, and to do it without a tc filter. In other patches: https://github.com/dtaht/sch_cake/pull/42 constifies things. (compile tested only, btw) And: I was not aware of this "feature": https://github.com/dtaht/sch_cake/issues/41 until yesterday and it needs testing against real traffic, on real RTTs. I think a lot of latency sensitive (and marked thus) traffic is now pretty bursty (videoconferencing in particular, as well as anything transiting a wifi hop beforehand) and (IMHO) the literature on short queues is now invalid and out of date for all but voice traffic. (that said, I'm willing to test first) ... stats keeping seems broken: https://github.com/dtaht/sch_cake/issues/43 I have always been allergic to all the stats in the first place. Keeping inaccurate stats is worse than no stats at all. ... I will gladly re-roll a patch for squashing. ... I would really like cake reviewed for suitability for mainlining before it becomes part of lede's next release. In particular the cobalt.*c* include has gotta go. ... I've done a bit of profiling on it, basically cpu-wise it eats about the same as htb+fq-codel does.