> On 26 Sep, 2016, at 16:28, moeller0 <[email protected]> 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

_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake

Reply via email to