Re: [Cake] Bandwidith rate by host instead of global while using [dual-]srchost and [dual-]dsthost

[Dave Taht <dave.taht@gmail.com>]

On Mon, Jun 11, 2018 at 8:43 AM, Michel Blais <michel@targointernet.com> 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
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619