[Cake] de-natting & host fairness

Kevin Darbyshire-Bryant kevin at darbyshire-bryant.me.uk
Mon Sep 26 10:06:57 EDT 2016



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 :-)



More information about the Cake mailing list