[Cake] de-natting & host fairness

[Jonathan Morton]

> On 26 Sep, 2016, at 16:28, moeller0 <moeller0 at gmx.de> wrote:
> 
> 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?

The initial packet will normally be outgoing, so it’ll go through conntrack before reaching the qdisc.  If it’s incoming, then it’ll be “related to” an existing connection or else won’t be natted - though I’m not sure whether “related” connections pre-emptively get conntrack entries before traffic has been seen.  If not, that initial packet will be associated with the NAT box by the qdisc, rather than the internal host, while subsequent packets will correctly be associated with the internal host.

That assumes we have qdiscs attached to the egress and ingress sides of a WAN-facing interface, as normally desired.

The code looks sane at first glance, so I’ll give it a try at my end.  With any luck, I’ll be able to improve triple-isolate’s performance enough to make that the default, too.  I should probably use a different data structure than a ring buffer, so that there is less in the way of linear searching for an unblocked flow.

The current default is “flows”, which doesn’t need NAT information to unambiguously distinguish flows from each other.  However, “hosts” mode does need it when running in a NAT environment, otherwise internal hosts will erroneously be lumped together with the NAT box.  Triple-isolate is effectively a combination of “hosts” and “flows” - that is probably the easiest way to understand it.

I think it is reasonable to turn on conntrack lookups by default whenever host information is relevant.  This is potentially true for all modes except “flowblind” and “flows”.

Also long overdue are the more subtle overhead compensation factor for PTM, and the two extra keywords for DOCSIS’ asymmetric overhead.

 - Jonathan Morton