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.
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?
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?
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.
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.
15 comments
[ 2.9 ms ] story [ 52.2 ms ] thread[1]: https://tinc-vpn.org
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)
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.
So large packets will always be better for your network.