This article a bit fishy to me. E.g.: > In almost all network stacks, per-flow IPsec processing is serialized due to implementation specific constraints of upp

This article a bit fishy to me. E.g.: > In almost all network stacks, per-flow IPsec processing is serialized due to implementation specific constraints of upper level protocols that require in-order packet processing and lower level hardware interfaces that are optimized for latency. The lack of concurrency, combined with memory copy requirements, inline cryptographic operations and multiple traversals of the network layer are to blame for poor performance. How is that different for the TLS solution? You still need somewhat in-order processing of the TLS stream, memory copies won't really go away with an additional TLS proxy, and the network layer traversals also aren't really that different. Sure one can put work into optimizing all of that, but that appears orthogonal to using TLS to me. What follows it the usual collection IPSec management downsides -- which may be true but shouldn't affect performance. IMO the interesting part is pretty far down the post: > Additionally, TLS record sizes are often larger than MTU (16KB vs 1500/9000B), resulting in lower setup costs for encapsulation. This may be the actual important change that affects the throughput. It would be interesting to see the effect on real workloads, i.e. not in synthetic benchmarks. Vice versa, it would also be interesting to see the same benchmarks with TLS record sizes limited to the usual MTU sizes. As the saying goes: I'm not impressed if your prototype is slightly better than what we have in production for years.