Could you also try dual-srchost on egress and dual-srchost on ingress, please.
These promise per-IP fairness at the first level and per-flow fairness "inside"
each IP. So if you think through it you can setup the ingress and egress
shapers to aim for per-internal-IP address which I believe is what you are
after. Triple-isolate is much harder to argue with, partly because it is
lacking a clear description what it does short of the source code, so it is
somewhat opaque what to expect in a given set of bidirectional flows. In short
you might have found a flaw in triple-isolate or it is working as intended,
which only JM will be able to answer. Cursory experiments in the past indicated
that a properly configured dual-srchost/dsthost pair on ingress and egress work
closer to a layman's expectations... Oh, with the new and shiny deNAT features
the dual-isolation options should now also work on a wan interface for IPv4,
thanks to Kevin's persistence.
On October 16, 2016 7:30:04 PM GMT+02:00, "G. Amanakis" <g_amana...@yahoo.com>
>I meant B gets always 1/3 of the bandwidth. It also gets worse if A is
>using bittorrent. The setup with cake doesn't involve tc-flow or
>marking packets with iptables.
>On October 16, 2016 11:57:03 AM EDT, "G. Amanakis"
>>I am trying the cobalt branch along with the 950-add-cake-to-tc.patch
>>from lede-git on Archlinux. However, I cannot get per-host fairness as
>>expected, neither with IPv4 behind NAT, nor with IPv6. Having host A
>>downloading from 2 sites and host B from 1, A gets always 1/3 of
>>available bandwidth. I am using "bestefforts triple-isolate nat" on
>>egress and ingress ifb of the WAN interface. Kernel 4.4.24 and 4.7.6.
>>The same setup with the same bandwidth limiting (3300kbit/900kbit)
>>works as expected with fq_codel, tc-flow using mark for hashing, and
>>iptables with HMARK using source egress ip for hashing and CONNMARK on
>Cake mailing list
Cake mailing list