On Mon, Jun 11, 2018 at 8:43 AM, Michel Blais <[email protected]> wrote: > Hi all, > > Is it possible while using srchost, or dual-srchost, and dsthost, or > dual-dsthost, to do a bandwidth limitation by host instead of global ? From > what I read, seem like not.
No. It's been one of those things where custom non-linux hardware is used on the head end (CMTSes, DSLAMs), where even trying seems futile. If there was a head-end maker that wanted to try (and sponsor the effort), that would be cool. One way to maybe get there without custom hw would be to insert a fat x86 or arm64 cake box in front of a CMTS or dslam as a transparent bridge (much like we see with certain dpi products) to do one veth per subscriber. We'd coalesce all the IPs a subscriber has into a cake instance # eth0 takes all traffic, eth1 outputs the reshaped traffic # bridge veth0,veth1 to eth1 # Route customer 1 ip route add 1.1.1.1 dev veth0 ip route add 2001::1:x:y:z/64 dev veth0 # Route customer 2 ip route add 1.1.1.2 dev veth1 ip route add 2001::2:x:y:z/64 dev veth1 tc qdisc add dev veth0 cake bandwidth 100mbit tc qdisc add dev veth1 cake bandwidth 20mbit Some comms from the head-end would be helpful to be monitoring the achieved rate (line noise issues) and global bandwidth available and tweaking each cake instance to suit every few seconds (tc qdisc change dev veth0 cake bandwidth 80mbit). Given that the latest cake is cracking 40gbit on a single interface, it might be interesting to see how hard we could push, say, 10,000 instances like the above through a big box to see what happens. But I tend to think the work should be layered onto a line card rather than a separate box. This is why we try so hard to make the code dual licensed and publish papers documenting the algoriths. 7 years after this effort started cable head-ends still use 2sec of FIFO buffering. I'd had high hopes we'd see *something* from arris by now that did more of the right thing. they tried sfq way back when https://pdfs.semanticscholar.org/c577/0612bfaa1dff4daf2b0cfe56b79627dddc9c.pdf and sfq is in one of their fiber products. I keep hoping we'll make some onts and gpon hardware soon, with bql + fq_codel at least. > I saw several times on messages on mailling list that some option could be > usefull for ISP and dual-srchost and dual-dsthost would seem something > usefull for small ISP, an alternative to Mikrotik PCQ with all the advantage > of cake like flow fairness and latency. Keep hoping that mikrotik will get on the ball. Many fq_codel requests on their forums. ubnt is all over this stuff. > Thanks > --- > Cordialement, / With regards, > > Michel Blais > > _______________________________________________ > 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
