[Cake] Using cake to shape 1000’s of users.

[Dan Siemon]

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 <fuller at beif.de> 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 at lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cake
> 
> 
>