On 06/04/17 11:45, Simon Matter wrote:
>
>> I like Arne's and David's suggestion - the existing option "as is" will
>> enable X% jitter, while a second parameter can specify a more specific
>> range. Following Arne's argument about users and percent math, it might
>> indeed be better to have "min max" here ("3500 3600"), because that is
>> really easy to understand and explain.
>
> After all the discussion I prefer the simple solution. I've changed my
> systems to the reduced 10% jitter and I'm wondering if it has to be made
> more complicated than this? I works very well and after some hours the
> renegs have spread very well. If you ask me it's perfectly fine that way
> as long as the docs clearly state that a pseudo random 10% us deducted
> from reneg-sec automatically to spread renegs.It must be configurable, based on many years experience with helping out on configuring OpenVPN tunnels. There are millions of OpenVPN configurations out in the world (and I don't even think I'm exaggerating that much even), many small ones and quite some large ones. There are VPN service providers with several hundred thousands paying customers, and there are an enormous amount of VPN service providers in addition. In addition to all the private and corporate deployments. So enforcing a good feature equally on all these configurations will backfire at us. And the more I think about the 10% randomness vlaue (or any percentage), I really wonder how clever that is. If a site uses --reneg-sec 1800 (I have seen that), that means a 3 minute window. If a site uses 14400 (4 hours, I've seen that too), that gives a 24 minute window. These window sizes may be perfectly fine. But depending on the amount of connected users, this may be troublesome too. Last night I chatted with krzee on #openvpn-devel about this. He does quite some cool stuff with OpenVPN and have lots of IP phones connecting to VPN servers. He said that randomness by default may not be ideal for some of the setups he manages. But he loves the idea behind this feature. Krzee argued that configurations explicitly setting --reneg-sec 3600 should not have any randomness. If a configuration does _not* set --reneg-sec, it may have randomness with 1 hour as the base. And those wanting better control of the time window should use: --reneg-sec min max I initially was of the opinion --reneg-sec 3600 should have randomness (the 10-17% base). But after having slept on it, I think Krzee have a good point. Setting --reneg-sec explicitly with only a single value should not have any randomness. With the 1 hour default, not setting --reneg-sec gives a time window of 6 minutes with 10%. That is a reasonable default unless explicitly overridden by either --reneg-sec 3600 (no randomness) or --reneg-sec 3000 4000 (with a 1000 seconds large time window) -- kind regards, David Sommerseth OpenVPN Technologies, Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
