Re: [Cake] cake separate qos for lan

[Dave Taht]

I gave this a shot, it doesn't route the packets back trhough the
underlying interface...
perhaps policy routing?

TC=/home/d/git/tc-adv/tc/tc
IFACE=eno1

F=2601:640:4103:56c0:2ab4:103a:39c5:a43a
S=2601:640:4103:56c0:120d:7fff:0:647

ip link add $IFACE name fast type dummy # maybe ifb?
ip link add $IFACE name slow type dummy # maybe ifb?

ip link set fast up
ip link set slow up

$TC qdisc add dev fast root cake bandwidth 20Mbit
$TC qdisc add dev slow root cake bandwidth 5Mbit
$TC qdisc add dev $IFACE root cake bandwidth 20Mbit

ip route add $F dev fast metric 1
ip route add $S dev slow metric 1
Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi


On Tue, Mar 29, 2016 at 4:31 PM, Dave Taht  wrote:
> An overall ISP in tc need exposed by this discussion is some means of
> mapping multiple ipv4 and ipv6 addresses and netmasks into something
> that will return a (key,value) pair. This would work something like
> ipset does, although what you would return is not "present or not" but
> present and a value
>
> insert customers 1.1.1.1,1
> insert customers 2001:db1::/64,1
> insert customers 2.2.2.2,2
> insert customers 2001:db2::/64,1
>
> then on the relevant path you'd set up the qdisc hierarchy and do a
> lookup into that to get the right number to go to the right cake
> instance. You'd also have to do a longest prefix match into the above,
> so a 1x1 hash won't do.
>
> the massive tc filter option discussed already does not scale to a
> random number of customers with randomly different numbers of ip
> addresses, types, and netmasks. Code like this must exist in dedicated
> devices already, CMTSes, BRASes, deep packet inspection devices, etc.
>
> Secondly, in the case of cake the hierarchy could just be a bunch of
> somewhat unassociated queues, not htb or drr, letting cake do the
> scheduling of deliveries.
>
> Regrettably I know of few ISPs that are actively using linux in any
> way they have sources to. I suspect a few dslams are linux based, but
> nobody's talking.
>
> ...
>
> Another way to maybe get there is to use the ip route functionality
> instead and send stuff to virtual devices layered on top of the real
> device.
>
> ip route add from :: to 1.1.1.0/24 dev dev1
> ip -6 route add from :: to 2001:db1::/64 dev dev1
> ip -6 route add from :: to 2001:db2::/64 dev dev2
> ip route add from :: to 2.2.2.0/24 dev dev2
>
> Then the reverse would be out one of two devices, one device
> configured for the "fast, local cache server", the other for the
> regular internet.
>
> solution too long to fit in the margins of this email.
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] cake separate qos for lan

[Dave Taht]

An overall ISP in tc need exposed by this discussion is some means of
mapping multiple ipv4 and ipv6 addresses and netmasks into something
that will return a (key,value) pair. This would work something like
ipset does, although what you would return is not "present or not" but
present and a value

insert customers 1.1.1.1,1
insert customers 2001:db1::/64,1
insert customers 2.2.2.2,2
insert customers 2001:db2::/64,1

then on the relevant path you'd set up the qdisc hierarchy and do a
lookup into that to get the right number to go to the right cake
instance. You'd also have to do a longest prefix match into the above,
so a 1x1 hash won't do.

the massive tc filter option discussed already does not scale to a
random number of customers with randomly different numbers of ip
addresses, types, and netmasks. Code like this must exist in dedicated
devices already, CMTSes, BRASes, deep packet inspection devices, etc.

Secondly, in the case of cake the hierarchy could just be a bunch of
somewhat unassociated queues, not htb or drr, letting cake do the
scheduling of deliveries.

Regrettably I know of few ISPs that are actively using linux in any
way they have sources to. I suspect a few dslams are linux based, but
nobody's talking.

...

Another way to maybe get there is to use the ip route functionality
instead and send stuff to virtual devices layered on top of the real
device.

ip route add from :: to 1.1.1.0/24 dev dev1
ip -6 route add from :: to 2001:db1::/64 dev dev1
ip -6 route add from :: to 2001:db2::/64 dev dev2
ip route add from :: to 2.2.2.0/24 dev dev2

Then the reverse would be out one of two devices, one device
configured for the "fast, local cache server", the other for the
regular internet.

solution too long to fit in the margins of this email.
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] cake separate qos for lan

[Toke Høiland-Jørgensen]

Jonathan Morton  writes:

> But maybe u32, in the hashing configuration, scales better.

I did a similar setup for a small ISP quite some time ago that used HTB
as the classful qdisc and a hashing u32 filter to divide traffic. This
was pre-FQ-CoDel, so it used SFQ on the leaves, but there's no reason
you couldn't just stick Cake on there.

Unfortunately I don't have the sources lying around anymore (and
probably couldn't share it if I did).

-Toke
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake