[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] LJ's "cons" of OpenVPN: how serious is latency?


  • Subject: Re: [Openvpn-users] LJ's "cons" of OpenVPN: how serious is latency?
  • From: Mathias Sundman <mathias@xxxxxxxxxx>
  • Date: Tue, 21 Dec 2004 23:10:40 +0100 (CET)

On Tue, 21 Dec 2004, J. Perkins wrote:

I was interested to see the LinuxJournal's "Meet OpenVPN" article:
http://www.linuxjournal.com/article/7949

The author lists a few "cons" of the program, including:
" - The OpenVPN process is executed in userland and, thus, is
relatively slow. TUN/TAP devices combine together with a
userland-process to create a setup in which traffic has to cross
userland/kernel borders relatively often. This setup might create
rather high latency on connections.

- A packet overhead is present because IP/Ethernet is encapsulated in
SSL and SSL in UDP/TCP."

I'm just wondering how important these considerations are in practice.
I realize that there are no doubt many factors which contribute, so let
me just give an example. I'm looking to set up a very small VPN with
1-3 (sporadic) "road warriors." Probably some remote desktop, but the
most common activity will be SMB browsing.

All pretty light weight, but the trick is much of the traffic will be
trans-Pacific (Oz/Canada). So my priority is perceived latency. When
somebody says OpenVPN is "relatively slow", is that "slow" in an
academic, computer-science inefficient inter-process communication sort
of way, or slow in a my-users-will-complain sort of way? (And what
"fast" VPN method are we comparing this to, anyway? IPSec?)

In the setup you are describing I'd definitly say it's the first -- "slow" as in academic, computer-science inefficient inter-process communication sort!


Your users will not complain!

IPSec has the potentional of beeing slightly faster (lower latancy) yes because of it residing in kernelspace rather than in userspace that OpenVPN does.

Judging by the raves OpenVPN gets on this list for both performance and
reliability, I wonder how big a deal this is. I considered the LJ
writer might be over-stating the case, I note he even takes the time to
repeat it in the last sentence: "If OpenVPN has a disadvantage, it
might be latency. However, no real-life data exists yet to back up that
claim." (No "real-life data"? So fake data exists?)

I agree that was abit over-stated. The only real latancy issue that really matter that I'm aware of is the current 2.0 mode server implementation which does not supports threads which causes rekeying to stall the tunnel. Per default rekeying only occurs once an hour, and the stall we're talking about is a only a matter of milliseconds (I don't remember the exact numbers, it has been discussed here on the list previously), but you would probably only notice it as small glitch during a VoIP conversation over an OpenVPN tunnel! For data tranmissions, you will never even notice it.


I havn't seen any real latancy measurements. Has anyone done any comparation of OpenSWAN and OpenVPN for instance?

--
_____________________________________________________________
Mathias Sundman                  (^)   ASCII Ribbon Campaign
OpenVPN GUI for Windows           X    NO HTML/RTF in e-mail
http://www.nilings.se/openvpn    / \   NO Word docs in e-mail

____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users