[strongSwan-dev] HA resync issue

[Emeric POUPON]

Hello,

I don't really know how it is actually done in the code, but it may be possible to reuse some IKEv2's UDP reliable mechanisms (Retransmission Timers, Windows, etc.)

I implemented a simple bandwidth limiter on the ha_socket, but it is quite complicated to properly set it up in order to provide the 'zero drop' feature (I have to set very conservative values).

Best Regards,

Emeric


----- Mail original -----
De: "Thomas Egerer" <hakke_007 at gmx.de>
À: dev at lists.strongswan.org
Envoyé: Samedi 30 Août 2014 00:08:19
Objet: Re: [strongSwan-dev] HA resync issue

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Martin,

On 08/28/2014 12:51 PM, Martin Willi wrote:
> Hi Emeric,
> 
>> I did not test using 1K or even 10K+ tunnels but the UDP based solution seems to be unable to provide the significant reliability needed for these cases.
> 
> I agree. For the setups I have used, a dedicated fast link was sufficient to have packet drops at an acceptable level. But certainly that could be very different on
> other setups, especially if the number of connections increases.
> 
>> I understand switching to a TCP based sync would require a significant work but it seems to be quite unavoidable.
> 
> Yes, HA definitely should have a reliable transport for sync messages. Not sure if TCP is the correct choice. At least for the heartbeat messages, we need controllable
> timeouts, which is difficult to implement with TCP.
> 
> So we either would have to separate heartbeat and synchronization functionality, or extend the UDP based protocol by message throttling and/or
> acknowledges/retransmissions. The latter could be achieved by extending the ha_cache class that already stores some messages for re-synchronization.
Just my 50 cents: having two seperate sockets for a) heartbeat (UDP) and
b) sync messages (TCP) sounds quite promising since you can hide all
this in ha_socket::push based on what needs to be pushed.
Extending ha_cache to have timers and retransmits (also queues for messages)
sounds like reimplementing TCP in user space.
But if there may a third option we haven't thought of: Martin will surely
figure it out ;)

Kind regards and a nice weekend

Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlQA+dMACgkQ2/ggQBUI/sn1XQCcC2/PrSDIiKzjQ+f3f1gQ1Crf
2loAoKHUQjhblEnumVM14vLrlAHVPfdd
=DrXG
-----END PGP SIGNATURE-----
_______________________________________________
Dev mailing list
Dev at lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/dev