Hello everyone,
Derek from OSTIF here. I've been working with OpenVPN for a few years and
there's a few curious performance anomalies that i've ran into that add up
to a possible performance opportunity. My experience lies closer to
networking protocols and cryptography rather than programming, so i'd need
some help confirming my suspicions to see if this is an opportunity for us.
I've been having some discussions with Mattock related to performance,
specifically the way that OpenVPN performance scales on fast networks.
The interesting symptoms:
-OpenVPN performance appears to decrease linearly with increases in latency.
-OpenVPN performance seems consistent regardless of the OS of the
client/server.
-OpenVPN performance seems to adjust/scale with the speed of the
client/server, but always seems limited to roughly 25% of the line speed of
the fastest device when you scale up to fiber speeds. The interesting part
is that 1Gb servers will top out around 220-275Mbit, and 10Gb servers will
top out around 2.5Gbit.
-OpenVPN performance increases when you manually increase the size of the
packets to oversized (MTU 9000+).
-Performance is similar between TCP/UDP barring confounding issues like
packet loss.
What conclusions can we draw from this?
My network experience points to something going awry with windowing with
TCP, but UDP does not apply any sort of windowing (no ACKs = no windowing)
but the OpenVPN protocol itself does have an ACK system, which suggests
that OpenVPN may apply its own windowing.
>From my network brain: These 4 factors all point to the same problem with
regular TCP networks, not enough packets are "allowed" to be in flight by
the protocol. This is why performance scales linearly with
distance/latency. The maximum number of packets in flight gets reached, and
the client/server then waits to send more or throttles back the rate to hit
the target number of packets per second based on the latency (how this is
done depends on how windowing is implemented). This is also why making the
packets larger increases performance. The OpenVPN protocol allows more
packets to be in flight indirectly, because a 9000 bit packet is broken
down into 1500 bit packets by the network protocol outside of OpenVPN, so
it sees fewer "packets in flight" at the OpenVPN level.
I'm also hesitant to blame issues like task-switching as the primary cause
of the issue because of the behavior being OS agnostic, and 10Gb
connections being able to move 2.5Gbit/sec.
This problem only seems to surface with high latency connections, or
particularly fast networks (over 1Gb),
Let me know if i'm drawing the wrong conclusions from the evidence here. I
think we may have a performance opportunity if we hack away at this issue
and come to a greater understanding of why OpenVPN behaves this way in
these cases. I'm also willing to do some Wireshark work to see how OpenVPN
behaves in these edge cases if we think it would be valuable.
Increasing performance for long-distance VPNs, and being able to
accommodate users in a fiber-to-the-home world would be a huge benefit for
all OpenVPN users.
Thanks for taking the time to read and respond!
Derek Zimmer
Chief Executive Officer
Open Source Technology Improvement Fund
------------------------------------------------------------------------------
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
