Re: [Cake] de-natting & host fairness

[moeller0 <moeller0@gmx.de>]

Hi Jonathan,

> On Sep 26, 2016, at 16:30 , Jonathan Morton <chromatix99@gmail.com> wrote:
> 
> 
>> On 26 Sep, 2016, at 16:28, moeller0 <moeller0@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.

	Okay, so the worst case is “regression” to simple flow fairness and only for initial packets. What about port redirects, will these be already included into the conntrack and what about UDP (I believe bit-torrent uses UDP so I believe this to be relevant).

> 
> 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.

	But the dual-[src\dst]host options are similar to triple-isolate in that regard except they also need directionality information which is hard to divine, so I fully agree that riple is the best candidate for a default. Assuming that it actually works…

> 
> 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.

	Teacher, teacher, ask me: the term you are looking for is “proper documentation”. 
About PTM what are you thinking about, the 64/64 encapsulation “tax”? 
About DOCSIS, while we have Greg White going on record for cable labs, would it not be wiser to survey more cable ISPs to check first whether everybody actually follows those recommendations before creating keywords? One thing I have learned about overhead compensation is, it never is as simple and nice as in real life as RFCs make you hope. I would love to be wrong on DOCSIS, but I believe the hypothesis should be someone set it up different. So in essence pan for a number of keywords for DOCSIS and name them in a way that allows future additions that do not sound awkward.

Best Regards
	Sebastian

> 
> - Jonathan Morton
>