[AusNOG] Anyone know of VPN's being bandwidth managed (throttled)

[Mark Smith]

On 6 January 2017 at 13:38, Peter Tiggerdine <ptiggerdine at gmail.com> wrote:
> My experience is is that PMTUD isn't configured correctly (or not
> allow to pass along the path).. Also endpoint CPU. encrypting and
> decrypting is heavy on CPU (assuming you have no offload engine).


You might be surprised how much encryption throughput you get these
days when encrypting/decrypting in software on a CPU.

On platforms that run openssl, you can measure crypto throughput for
various algorithms using 'openssl speed'.

I've found that CPU software crypto under Linux on a 2009 era Intel
Q6600 is fast enough that I can encrypt the filesystems on that
machine and not notice the performance impact. Measuring using
'cryptsetup benchmark' shows worst case throughput of 105.1 MiB/s for
aes-xts, which is what Fedora uses for filesystem crypto. My HDDs (WD
2TB Blacks) do 123.58 MB/sec according to 'hdparm -t', so I am
sacrificing some HDD performance but it isn't noticeable.

I wonder how many people are aware that modern Intel and AMD CPUs have
hardware AES crypto engines in them (known as 'AES NI' instructions)?
My 2013 Dell XPS laptop with an Intel Core i5 in it, using 'cryptsetup
benchmark', does worst case 1040 MiB/s aes-xts encryption/1060.1 MiB/s
decryption, which is more than twice the 426.53MB/s the SSD can do
(and around 10 times what my Q6600 does in software), so filesystem
crypto is not going to be the IO bottleneck.

Using simple 8 bits per byte maths, that means my 2013 laptop could do
more than 8 Gbps of CPU crypto engine throughput. So if the CPU's AES
engine is used for VPN crypto, most people aren't going to have any
crypto throughput problems with a VPN (Peter Löthberg's grandma being
a possible exception).

(I encrypt all my filesystems these days, not because I'm paranoid and
think the government is out to get me, but because it is easier to
know that if any one of my computers is stolen, they've stolen my
hardware but not my data.)

Regards,
Mark.