On 26/09/16 14:28, moeller0 wrote:
Hi Kevin,
This really needs to be tested. As I mentioned the 'ingress' side
of things is harder work because the kernel hasn't filled in the
conntrack pointer for us. There are some remaining concerns over
how reliable our own lookup actually is. The conntrack entry
'direction' is apparently determined by where it is seen first,
there are then 2 tuples created in the 'original' and 'reverse'
directions. This made me think that a connection initiated by the
router vs a connection initiated from outside into it (even if
natted) would have the src & destination fields swapped...however
in my limited testing 'who started the connection' appeared to make
no difference. But conntrack makes my brain cell hurt.
Does that mean an initial packet(s) for a flow will be
“misclassified” (not really since there should be no record yet to
snatch the translated IP from) do all those initially non-classified
packets end up in the same bin? (I guess even if that should not
matter too much unless in extreme situations and those merit extreme
reactions anyways)
That was certainly one of my concerns, however the simplistic testing I
performed showed that somehow a translation was in place. The
simplistic testing being setting up a port forward to an internal lan
host, connecting to it from the wan side with another device and dumping
the addresses seen by the qdisc with printk. The test may be flawed, my
execution of the test flawed etc. I expected the test to fail, however
it passed!
I'm sure there are people on this list who are a) much cleverererer
than me and b) know conntrack upside down & backwards. Help is as
ever gratefully received.
Regarding IPv6 vs IPv4: As it currently stands the code does
conntrack lookups for both so if someone is translating IPv6
addresses then we know about it. I’m now thinking about making
IPv6 lookups a runtime option (default off)
That would allow to easily measure the cost of those lookups.
I've done half the job...updated the qdisc. I need to update tc to
allow/report the ipv6 de-nat status.
From a flow/host fairness point of view I really don't care if a
one to one address translation has occurred...and if someone really
does implement a 'masquerading many hosts behind one IPv6 address'
environment...and they still want per IP & per flow fairness then
unmentionable things should be done to them.
I'm not a fan of de-natting by default. Per IP fairness is not the
default and requires at least one of the 'dual-???host' or
'triple-isolate' options to be relevant. I’ve also concerns on CPU
usage.
Mmh, I would have thought that even for srchost and dsthost (note no
dual) it would make sense to allow to deNAT? If we default to deNAT
we might also default to triple-isolate, assuming that it actually
works… Cake offers to refine the hashing for discerning users, but
for everybody else we should pick well working defaults. Cake not
being upstream yet is a virtue as we will not need to argue against
the “no unexpected surprise behavior change” policy that seems to be
used in the kernel (no argument from my side, for the kernel that
seems a good policy, but we still can try to upstream the most useful
deaults for “my mom”).
Forgot about the srchost/dsthost only options :-)
CPU usage is difficult to quantify. As a rough guestimate my
Archer C7 used about 10% cpu per megabit. I’d say that has gone up
by 2% percent with this change, so it is heavy!
That is a tad high; maybe too high for making it a default but still
it would be nice having a qdisc that by default does what naive users
expect a(ll) qdisc(s) to do ;)
The de-nat ipv6 tweak may have also introduced a small
optimisation...depending on how clever the compiler is.
The code is out there, if you’ve an itch...scratch it :-) Fork it,
improve it etc but please don't think I'm any sort of kernel guru
:-)
Yepp, I really need to get my own LEDE builds going so I can start
playing around with that again. (I am slow with that as my typical
use cases at home work pretty well with what we have right now; and I
somehow don’t want to start with heavy bit-torrenting (how many
debian DVD images could I actually ever need?) or windows10
updates).
Ha! Bet you can't guess what I used as a download source for testing
purposes :-)
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
