4 ms·

>Is WireGuard faster than other VPN solutions? >Simple answer: It isn't. It's really hard to not dismiss this guy as an utter clown when it's so obvious he's

by FDSGSG 7y ago

>Is WireGuard faster than other VPN solutions? >Simple answer: It isn't. It's really hard to not dismiss this guy as an utter clown when it's so obvious he's making these claims without even trying wireguard.

wmf 7y ago
The author seems to have enough experience with IPSec that people would dismiss his first-hand experience or benchmarks as biased anyway.
- gonzo 7y ago
  > The author seems to have enough experience with IPSec that people would dismiss his first-hand experience or benchmarks as biased anyway. OK, if you want to claim bias... I own the company behind pfSense, and am sponsoring the work to put wireguard in the FreeBSD kernel (and will pay for the additional work to put this work in pfSense.) He's right, wireguard will be no faster than IPsec given equivalent encryption schemes (say, if IPsec were to use ChaCha20-Poly1305 for the bulk encryption) because the framing overheads are within a few bytes of each other. And if you're willing to compare AES-GCM to ChaCha20+Poly1305, then AES will, indeed, almost always be faster. The author makes note of the AES-NI instructions, and Wireguard's claim to be able to use the vector (AVX512) instructions, > The WireGuard whitepaper mentions due to AVX512, ChaCha20-Poly1305 will outperform AES-NI1, but that instruction set extension will only be available on large processors which again won't help with smaller and mobile hardware that will always be faster with AES-NI. However: 1) using the vector units from inside the kernel will involve a lot more overhead if anything else (say, in user land) is using the vector unit(s). Welcome to vector context switch overhead. Tons of huge registers to save and restore. 2) near future versions of AVX512 [https://eprint.iacr.org/2018/392.pdf https://eprint.iacr.org/2018/392.pdf] will support vector versions of the AES-NI (VAES) and PCLMULDQD (VPCLMULDQD) instructions. These have been timed at over 150Gbps. Yes, that's correct.
  - loeg 7y ago
    > 1) using the vector units from inside the kernel will involve a lot more overhead if anything else (say, in user land) is using the vector unit(s). Welcome to vector context switch overhead. Tons of huge registers to save and restore. FWIW, x86 AESNI instructions also operate on the XMM vector units. Doing AESNI in the kernel involves much of the same overhead as accelerated Chacha. (No comment on AVX512 and future directions — I'll take your word for that part.)
1_person 7y ago
You don't need to try WireGuard to understand it will not be as fast as bump in the wire IPsec implemented in ASIC, which is available today from literally dozens of vendors at 100Gbps+. It is also possible to recognize without trying WireGuard that it has more protocol overhead, access to fewer ciphers than IPsec, and access to no ciphers that IPsec does not support. This means that IPsec encryption will be as fast or faster in all cases and IPsec framing will be more efficient in all cases, all else being equal.
- FDSGSG 7y ago
  >You don't need to try WireGuard to understand it will not be as fast as bump in the wire IPsec implemented in ASIC, which is available today from literally dozens of vendors at 100Gbps+. But what does that have to do with anything? Wireguard certainly doesn't compete with IPsec ASICs. >all else being equal Unfortunately we live in the real world where this assumption doesn't hold true.
  - 1_person 7y ago
    > But what does that have to do with anything? Wireguard certainly doesn't compete with IPsec ASICs. I appreciate that you are not making that claim and I'm glad that we agree. However, that "WireGuard is faster than IPsec" is exactly what the authors are claiming without qualification, and supporting with controversial data, on the official website. As such I believe examination of the claim is justified. > Unfortunately we live in the real world where this assumption doesn't hold true. Yet we are in a rational discussion of the merits of the two protocols, in which outliers that introduce additional variables should be first discovered, then examined individually, rather than dismissing the first order effects out of hand on the supposition that outliers influenced by additional variables may exist.
    - FDSGSG 7y ago
      >However, that "WireGuard is faster than IPsec" is exactly what the authors are claiming without qualification The same blog post also extensively discusses OpenVPN, then goes on to state "Is WireGuard faster than other VPN solutions? Simple answer: It isn't." This question presented in the post wasn't "Is WireGuard faster than all other VPN solutions?" >Yet we are in a rational discussion of the merits of the two protocols, in which outliers that introduce additional variables should be first discovered, then examined individually, rather than dismissing the first order effects out of hand on the supposition that outliers influenced by additional variables may exist. Are we discussing protocols or the implementations? One of these seems far more practical to me. I'd personally love to see this benchmark where a sane IPsec configuration running on regular commodity hardware beats WG throughput.

by FDSGSG 7y ago

wmf 7y ago

The author seems to have enough experience with IPSec that people would dismiss his first-hand experience or benchmarks as biased anyway.

gonzo 7y ago
> The author seems to have enough experience with IPSec that people would dismiss his first-hand experience or benchmarks as biased anyway. OK, if you want to claim bias... I own the company behind pfSense, and am sponsoring the work to put wireguard in the FreeBSD kernel (and will pay for the additional work to put this work in pfSense.) He's right, wireguard will be no faster than IPsec given equivalent encryption schemes (say, if IPsec were to use ChaCha20-Poly1305 for the bulk encryption) because the framing overheads are within a few bytes of each other. And if you're willing to compare AES-GCM to ChaCha20+Poly1305, then AES will, indeed, almost always be faster. The author makes note of the AES-NI instructions, and Wireguard's claim to be able to use the vector (AVX512) instructions, > The WireGuard whitepaper mentions due to AVX512, ChaCha20-Poly1305 will outperform AES-NI1, but that instruction set extension will only be available on large processors which again won't help with smaller and mobile hardware that will always be faster with AES-NI. However: 1) using the vector units from inside the kernel will involve a lot more overhead if anything else (say, in user land) is using the vector unit(s). Welcome to vector context switch overhead. Tons of huge registers to save and restore. 2) near future versions of AVX512 [https://eprint.iacr.org/2018/392.pdf https://eprint.iacr.org/2018/392.pdf] will support vector versions of the AES-NI (VAES) and PCLMULDQD (VPCLMULDQD) instructions. These have been timed at over 150Gbps. Yes, that's correct.
- loeg 7y ago
  > 1) using the vector units from inside the kernel will involve a lot more overhead if anything else (say, in user land) is using the vector unit(s). Welcome to vector context switch overhead. Tons of huge registers to save and restore. FWIW, x86 AESNI instructions also operate on the XMM vector units. Doing AESNI in the kernel involves much of the same overhead as accelerated Chacha. (No comment on AVX512 and future directions — I'll take your word for that part.)

1_person 7y ago

You don't need to try WireGuard to understand it will not be as fast as bump in the wire IPsec implemented in ASIC, which is available today from literally dozens of vendors at 100Gbps+. It is also possible to recognize without trying WireGuard that it has more protocol overhead, access to fewer ciphers than IPsec, and access to no ciphers that IPsec does not support. This means that IPsec encryption will be as fast or faster in all cases and IPsec framing will be more efficient in all cases, all else being equal.

FDSGSG 7y ago
>You don't need to try WireGuard to understand it will not be as fast as bump in the wire IPsec implemented in ASIC, which is available today from literally dozens of vendors at 100Gbps+. But what does that have to do with anything? Wireguard certainly doesn't compete with IPsec ASICs. >all else being equal Unfortunately we live in the real world where this assumption doesn't hold true.
- 1_person 7y ago
  > But what does that have to do with anything? Wireguard certainly doesn't compete with IPsec ASICs. I appreciate that you are not making that claim and I'm glad that we agree. However, that "WireGuard is faster than IPsec" is exactly what the authors are claiming without qualification, and supporting with controversial data, on the official website. As such I believe examination of the claim is justified. > Unfortunately we live in the real world where this assumption doesn't hold true. Yet we are in a rational discussion of the merits of the two protocols, in which outliers that introduce additional variables should be first discovered, then examined individually, rather than dismissing the first order effects out of hand on the supposition that outliers influenced by additional variables may exist.
  - FDSGSG 7y ago
    >However, that "WireGuard is faster than IPsec" is exactly what the authors are claiming without qualification The same blog post also extensively discusses OpenVPN, then goes on to state "Is WireGuard faster than other VPN solutions? Simple answer: It isn't." This question presented in the post wasn't "Is WireGuard faster than all other VPN solutions?" >Yet we are in a rational discussion of the merits of the two protocols, in which outliers that introduce additional variables should be first discovered, then examined individually, rather than dismissing the first order effects out of hand on the supposition that outliers influenced by additional variables may exist. Are we discussing protocols or the implementations? One of these seems far more practical to me. I'd personally love to see this benchmark where a sane IPsec configuration running on regular commodity hardware beats WG throughput.