On 06/04/17 14:05, Gert Doering wrote: > Hi, > > On Thu, Apr 06, 2017 at 01:49:04PM +0100, debbie10t wrote: >> As you can see, the current proposal does not allow for first random, >> followed by expected/normal/regular renegs. It is either *always* random >> or *never* random .. I believe this is a poor decision. > > Your voice has been heard, and nobody else of the core team has been > convinced. It is not necessary to repeat that more often.
I believe the core team has made a poor decision and I am trying to explain clearly "why". Take for example: Company A has 1,000 vpn users and (for what ever reason) they reboot the server every 24 hours. They experience the slow down because all their vpn users are permanently connected. They all connect at once. This patch is not trying to address the initial connect it is trying to address the subsequent reneg's all happening at once. So, Company A decides to use --reneg-sec max min Subsequently, Company A receive a flood of complaints from users who are being constantly randomly reneg'd .. when they are accustomed to regular hourly reneg's. Company A either disables the randomisation .. or tells their users "what" ? The only justifiable randon reneg is the first one and Company A would be able to explain that to their users, that they must experience one random reneg or they all experience slow down at hourly intervals. Regards ------------------------------------------------------------------------------ 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
