On Thu, Jul 26, 2018 at 8:46 AM Dan Siemon <[email protected]> wrote: > > 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.
AWESOME. I am curious as to how high you can scale currently? (subscribers, bandwidths) > 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 <[email protected]> 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 > > > [email protected] > > > https://lists.bufferbloat.net/listinfo/cake > > > > > > > -- Dave Täht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619 _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
