Performance Analysis of VPN Gateways (2018) [pdf](net.in.tum.de)
net.in.tum.de
Performance Analysis of VPN Gateways (2018) [pdf]
https://www.net.in.tum.de/fileadmin/bibtex/publications/theses/2018-pudelko-vpn-performance.pdf
4 comments
Advisor of this thesis here; happy to answer questions
interesting work and (not cs graduate degree here) good output for MS thesis i'd say.
however it does seem to ignore other parallelism / userspace / packet processing efforts in other systems (freebsd netmap/negraph, netbsd bpfjit, the original BPF itself, etc) and 'confuse' layers of kernel vs userspace and pkt forwarding vs vpn - for example if userspace vs kernelspace networking stack is a 'solved' performance problem for custom applications, should not the focus be on comparing this toolkit with several kernel or kernel-bypassing mechanisms? that said, the comparison does seem 'complete' internally w/r/t the linux platform, so perhaps i should be less critical - esp since not everything can be done in a short time as for masters paper and this is more than I ever did:) . I suppose but given the amount of research and tools out there, some rationale as to the 'selection'/'combination' of presented aspects and a nod to these other areas as at least existing in the literature and having been considered in the topic i think would make this stronger.
still a good read and definately very well written/tested within the topic area, the instrumentation and using fast dynamic languages for prototyping and attempts to quantify vpn performance w/r/t packet processing & cpu i think is great from 'methods'/'theory' perspective.
however it does seem to ignore other parallelism / userspace / packet processing efforts in other systems (freebsd netmap/negraph, netbsd bpfjit, the original BPF itself, etc) and 'confuse' layers of kernel vs userspace and pkt forwarding vs vpn - for example if userspace vs kernelspace networking stack is a 'solved' performance problem for custom applications, should not the focus be on comparing this toolkit with several kernel or kernel-bypassing mechanisms? that said, the comparison does seem 'complete' internally w/r/t the linux platform, so perhaps i should be less critical - esp since not everything can be done in a short time as for masters paper and this is more than I ever did:) . I suppose but given the amount of research and tools out there, some rationale as to the 'selection'/'combination' of presented aspects and a nod to these other areas as at least existing in the literature and having been considered in the topic i think would make this stronger.
still a good read and definately very well written/tested within the topic area, the instrumentation and using fast dynamic languages for prototyping and attempts to quantify vpn performance w/r/t packet processing & cpu i think is great from 'methods'/'theory' perspective.
Yeah, that's out of scope.
Out of curiosity, how would TINC VPN [1] compare to the results you obtained? I’ve been using it to interconnect a HA Kubernetes cluster and so far it hasn’t been disappointing.
[1]: https://tinc-vpn.org
[1]: https://tinc-vpn.org
Probably similar to OpenVPN as the performance-critical parts are similar.
Any thoughts on when we might see MoonWire VPN made publicly available, and something the rest of us could play with in comparison to tools like IPSec, OpenVPN, and WireGuard?
Code is on GitHub: https://github.com/pudelkoM/MoonWire
It's not designed for any kind of production use and we have no plans to develop this further. It's only a quick and dirty example implementation of several possible architectures to get some ideas about the performance impacts of architectural design decisions.
Also, it's academic code, that means it's poorly documented and designed to run only the benchmarks that we needed. (But I do think it's above average quality for academic code)
It's not designed for any kind of production use and we have no plans to develop this further. It's only a quick and dirty example implementation of several possible architectures to get some ideas about the performance impacts of architectural design decisions.
Also, it's academic code, that means it's poorly documented and designed to run only the benchmarks that we needed. (But I do think it's above average quality for academic code)
Considering that OpenVPN saw almost perfectly linear improvement with multiple processes with no sign of slowing down, it seems bit odd and arbitrary to stop at 16 processes. Was it explored further to see where the scaling hits limits?
The test machine has 20 cores (+ hyper-threading) and we dedicated the first 4 to the NIC driver.
Why not test open source against a cheap 5505 from eBay or something?
FYI: I'm not the author
Does the type of data or usage effect the relative speeds. eg Torrenting vs regular browsing, etc.
It should, as encryption/decryption is done on a packet basis.
You can send 1 Mb packet or 1000 1k packets.
Per-packet overhead dominates over per-byte overhead. This is true for almost all network functions, even if they perform heavy calculation on the payload like encryption.
So large packets will always be better for your network.
So large packets will always be better for your network.
[deleted]