Re: [Cake] Pre-print of Cake paper available

[Sebastian Moeller <moeller0@gmx.de>]

> On Apr 24, 2018, at 09:15, Pete Heist <pete@eventide.io> wrote:
> 
> 
>> On Apr 24, 2018, at 7:58 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
>> 
>> Turning NAT support on by default might actually be reasonable, since it doesn't really break anything if it's not needed - it just eats a bit of CPU with unnecessary conntrack lookups.
> 
> I would be for it, if it eats say < 1% additional CPU, and preferably less. I expect the impact to increase with packet rates.
> 
>> For the flowmodes, basically triple-isolate's raison d'être is to be a reasonable default which (usually) gives most of the benefits of the "dual" modes, without needing to know a-priori anything about network topology.  In the most typical application, the distinction can be seen in whether the qdisc is attached to an IFB or a physical interface, but in deployments that we'd *like* to see, the opposite cases easily occur.  To do anything more sophisticated, we'd need to watch some traffic and guess after a while, and that doesn't feel right.
> 
> Yeah, I see. The same could be done with nat. There could be an auto-detect phase where nat lookups are performed and not to determine if it’s needed. But if these detections didn’t work with near-perfect reliability, it would complicate troubleshooting.


IMHO, auto-detection would at least require a dedicated keyword, like "detect-nat" that would be reported in the tc -s qdisc output for cake as long as the detection phase is active and would be replaced by the appropriate "nat" or "nonat"
keyword in the tc -s qdisc output after the phase is done (there should be no ambiguity). But overall I believe that this is adding more confusion. That said I am all for making nat the default, even though it would be nice to have measurements showing its cost. 


> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake