[Cake] Cake implementations

[Justin Kilpatrick]

>  An idea which was floated was to experiment with routing ISP customer 
> >traffic through a Linux server using cake to improve customer 
>  experience.  Basically like Preseem.  My colleague has toyed with it a 
> >bit in small test cases and was impressed with the outcomes.

Althea.net runs Cake at every hop. Since we use Babel to dynamically generate the network topology we rely on it's neighbor RTT extension and bandwidth counters to reduce the bandwidth over a link when an intermediate device has decided to become bloaty. 

It's been a very effective system that results in happier customers even when we have weak leaks or crazy failover situations. Usually wireless links have to be over provisioned by a factor of 2ish to keep latency under control in the face of dynamic interference and other external factors. Instead Althea networks have more smaller links then back links between each pop.

Traffic is then load balanced based on latency and when an antenna starts to really go crazy due to overloading the auto tuner clamps down Cake until the experience is good again. 

-- 
  Justin Kilpatrick
  justin at althea.net

On Fri, Nov 22, 2019, at 6:46 AM, Toke Høiland-Jørgensen wrote:
> "Adam Moffett" <adam at plexicomm.net> writes:
> 
> >>>
> >>>  Are there any commercial products already using Cake?
> >>
> >>Evenroute, eero, ubnt top that list. Evenroute's implementation is
> >>superb, the first one that used active line measurements to handle
> >>"sag". Anything derived from openwrt (somewhere between 10-30% of the
> >>home router market). I'm not sure if preseem is using it or not.
> >>dd-wrt. Most other things doing "SQM" are doing it via htb + fq_codel.
> >>
> >>
> > An idea which was floated was to experiment with routing ISP customer 
> > traffic through a Linux server using cake to improve customer 
> > experience.  Basically like Preseem.  My colleague has toyed with it a 
> > bit in small test cases and was impressed with the outcomes.
> >
> > He's looked closer than I have, but I'm trying to picture how his idea 
> > would scale.  I believe I'm seeing a CLI tool for configuring policies.  
> > It seems like we'd have to create a middle layer to create/update 
> > policies for customer's IP address based on information obtained from 
> > our AAA and CRM systems.  I can picture some shapes that might take, but 
> > I think it would ultimately have to revolve around scripting the tc 
> > command.  There would be thousands of policies and a policy would be 
> > created/updated whenever a subscriber reconnects (e.g. when a DHCP lease 
> > renews or a RADIUS auth event happens or similar).
> 
> I know several ISPs that do this (route traffic through a Linux box and
> shape there). This deployment mode has not been the primary focus of
> CAKE, though; the "standard" way to do it is with HTB+FQ-CoDel, which
> allows you to set up arbitrarily complex configurations on a single
> interface. This can also be made to scale, but there's a central qdisc
> lock in Linux that you have to get around to scale to multiple cores.
> Fortunately, Jesper has already solved this particular issue:
> 
> https://github.com/netoptimizer/xdp-cpumap-tc
> 
> > Should we even pursue this idea?
> 
> In my own totally non-biased opinion: Yes! :)
> 
> > Although most staff who would touch this will have studied programming 
> > in college, I would not qualify any of us as "programmers" per se.  My 
> > biggest concern would be hitting a service affecting problem that we 
> > can't solve.
> 
> One way to go about this would be to open source the entire solution.
> There are already bits and pieces available as open source (such as
> Jesper's repository above, and sqm-scripts[0]) that you can build on,
> and this way you could enlist community help to solve any issues with
> the Linux side. You'd still need to get the data from your internal
> systems, of course, but you could define a simple configuration format
> that was part of the open source code; then you'll just need to write a
> script that grabs customer info from your CRM and outputs the config
> format...
> 
> > Second concern is that many of our equipment vendors already use
> > Linux. Even Cisco now in some products. Maybe we'll waste our time
> > trying to roll our own solution and then find that a software update
> > from a vendor next year gives us everything we needed anyway.
> 
> This would be great, of course, and do go and bug your vendors to solve
> this problem! Note, however, that just because a system is running
> Linux on the control plane, it may be using a hardware-offloaded data
> plane that does not have any of the bufferbloat mitigation features
> (unless the vendor specifically implemented them). I'm hoping that
> *eventually* these things will be ubiquitous across the industry, but
> thus far this has seemed to be an "any decade now" kind of proposition :/
> 
> -Toke
> 
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>