From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from alpha.coverfire.com (alpha.coverfire.com [69.41.199.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E21F83B2A4 for ; Thu, 26 Jul 2018 11:46:37 -0400 (EDT) Received: from neptune.home (pkt.206.174.packetworks.net [206.174.180.53] (may be forged)) (authenticated bits=0) by alpha.coverfire.com (8.15.2/8.15.2) with ESMTPSA id w6QFkWBq011790 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 26 Jul 2018 11:46:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=coverfire.com; s=alpha2011102501; t=1532619993; bh=c+Z4i5SRuXw/NGaDt8jNxEwkH3V10aYJ/sfI5DqNa0w=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=YV9f15BXHAwCxJEKffiIA79cXlQWh5B0XzV5FerEHpTg0fQXjH0KTgWL86RGx2rLE vlOACpVhSG4gtWT8CskDUOJXRC5IWyqlPUfx/SAFPOeTJCF6UH3mBw/tRZdp6AV1cn Q8lrWaTgPjR5c9X8Mv0qp9IeTug/QGou9pUd3ACM= Message-ID: <1c323544b3076c0ab31b887d6113f25f572e41ae.camel@coverfire.com> From: Dan Siemon To: Dave Taht , fuller@beif.de Cc: Cake List Date: Thu, 26 Jul 2018 11:46:32 -0400 In-Reply-To: References: <1357421162.31089.1531812291583@webmail.strato.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.4 (3.28.4-1.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 69.41.199.58 X-Spam-Status: No, score=-1.1 required=5.0 tests=ALL_TRUSTED, DATE_IN_FUTURE_96_Q,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on alpha.coverfire.com Subject: Re: [Cake] =?utf-8?q?Using_cake_to_shape_1000=E2=80=99s_of_users=2E?= 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: Thu, 26 Jul 2018 15:46:38 -0000 Tiny bit of self promotion here but Preseem (https://www.preseem.com) is a transparent bridge that leverages HTB/FQ-CoDel to make subscriber plan enforcement provide much better QoE. Leaving enforcement up to the deep queues in most network equipment has comparably very bad results. We focus on WISPs but we have customers that provide service via DSL and cable as well. We leverage an eBPF classifier to direct each subscriber's traffic into an HTB class that matches their plan rate and within that is an FQ- CoDel instance. This classifier handles the various encapsulations we need to support in ISP networks. I haven't had time to try Cake in this context yet but hope to get to that in the next couple months. I believe this will require one Cake instance per-subscriber like we do with FQ-CoDel today. On Tue, 2018-07-17 at 09:59 -0700, Dave Taht wrote: > On Tue, Jul 17, 2018 at 12:24 AM Felix Resch wrote: > > > > since commercial interest is involved, see here > > https://lists.bufferbloat.net/pipermail/cake/2018-June/003861.html > > I grew that list substantially in the ending talk. It was motivating. > :) I am thinking of doing something similar (with editorial comments) > pointing > to each of dslreports' values per ISP, like, for example, leveraging > > http://www.dslreports.com/speedtest/results/bufferbloat?up=1 > > To kvetch while pointing further to stuff like: > > http://www.dslreports.com/speedtest/results/isp/r3910-google-fiber > http://www.dslreports.com/speedtest/results/isp/r2784-t-mobile > http://www.dslreports.com/speedtest/results/isp/r896-sonic > http://www.dslreports.com/speedtest/results/isp/r1579-Comcast%20XFINITY > > That angst out, ISPs and vendors that want to work with us to > establish requirements and code for a transparent > bridge/veth/cake-like thing are very welcome at any point! The core > factor stopping us from even trying isn't lack of money or time... it > is not knowing of *any* head-end equipment (DSLAM/CMTS/GPON/etc) that > could be modified by us to have better queue management in the first > place, and a transparent bridge seems second best, at best, with > complexities involving ipv6 and ipv4 support, sag, nat, vlans, etc, > etc - so we've focused on fixing the edge device itself, and making > available published open source code and standards in the hope that > some head-end vendor would pick it up... after being suitably nagged > by their ISP customers. Or the sandvine type middlebox folk. > > Also, in terms of angst, we hope merely that ISPs would start > supplying CPE that has our stuff in it (particularly since the > aftermarket already has it, and it works in even the cheapest boxes > made today), and either autoconfigure to their set rates, with cake, > or supply that information to their end users to configure. It's been > 6 years since the code hit the embedded world.... I'm pleased to say > that "fq_codel for wifi" derivatives seem to propagating rapidly, at > least. Maybe a fortigate or barracuda will ship some kind of smart > queue management one day soon... if enough customers ask for it. > example: https://forum.fortinet.com/tm.aspx?m=163978 > > on the transparent bridge front... Linux has issues scaling to high > rates *on the receive path* at 10gigE+ speeds. > > I've certainly lain awake at night dreaming of what we could do with > a > smart line card for a cmts, or even a small dslam. > > > _______________________________________________ > > Cake mailing list > > Cake@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/cake > > >