> On Jul 28, 2018, at 10:06 AM, Jonathan Morton <[email protected]> wrote: > > This sounds like a relatively complex network topology, in which there are a > lot of different potential bottlenecks, depending on the dynamic state of the > network.
It is, which is the argument from those who want a more centralized approach. Backhaul link types include 5 GHz, 10 GHz, 60 GHz, licensed spectrum (apparently), and some fiber. Side note: I’ve heard that aligning the 60 GHz p2p links is a chore. > Okay, so straight away we're in a significantly different regime from > CoverFire's situation, where the subscribers each have a defined link > bandwidth (which may or may not be related to the capabilities of the > underlying physical link). You simply need to share some backhaul link > fairly between subscribers using it at any given moment. Exactly. Many members, including myself, are limited by our CPE links during off hours, and by the backhaul during high traffic hours. > Let's call this one a vote for "diffserv not required", since DRR++ copes > well by prioritising sparse traffic. Yep, I don’t know if you’ll hear “diffserv required” for an ISP, but we’ll see. > Could you convert that DB to eBPF rules? This would let you use the same > configuration interface as CoverFire's situation. That should be no problem at all. > In general, I think the make-wifi-fast team has a better handle on the > subtleties of half-duplex links. If there's any way to get their work into > the airOS devices, so much the better. I wish that were the case, but am not holding my breath. As things stand now, I may still use HTB then, which is ok. The key is not just the dynamic rates, but also, it appears, having egress and ingress through a common IFB that’s split into sub-queues for egress and ingress. I’ll punt on WiFi for now and come back to it later. > But I think there's also a use for "ISP-type" Cake in your network, > especially in the wired backhauls where link bandwidth is relatively > predictable, and I suspect most of these will be in the core parts of your > network where the traffic is most complex. As long as you can get around to > running a suitable kernel version, there should also be no inherent problem > with replicating the same dynamic adjustment of global shaper rate as > "normal" Cake has, which will allow it to be used on some of your wireless > links as well. Yes, the biggest benefit for us would probably be “member fairness” instead of “IP fairness”. One of the long-time admins was excited that this might be possible. Also, I’ll be interested to see if improving queue management gets us better utilization of the Internet link. If so, we may want fairness at the gateway, which may be a job more for an ISP Cake given the number of flows. Lastly, if ISP Cake could support SMP, that would be all the better for the dual and quad core APU backhaul routers. :)
_______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
