Re: Packet Number Encryption Performance

[Kazuho Oku <[e-mail]>]

Hi Nick,

Thank you for bringing the numbers to the list.

I have just run a small benchmark using Quicly, and I see comparable
numbers.

To be precise, I see 10.0% increase of CPU cycles when encrypting a Initial
packet of 1,280 octets. I expect that we will see similar numbers on other
QUIC stacks that also use picotls (with OpenSSL as a backend). Note that
the number is only comparing the cost of encryption, the overhead ratio
will be much smaller if we look at the total number of CPU cycles spent by
a QUIC stack as a whole.

Looking at the profile, the overhead consists of three operations that each
consumes comparable CPU cycles: core AES operation (using AES-NI), CTR
operation overhead, CTR initialization. Note that picotls at the moment
provides access to CTR crypto beneath the AEAD interface, which is to be
used by the QUIC stacks.

I would assume that we can cut down the overhead to somewhere between 2% to
4%, but it might be hard to go down to somewhere near 1%, because we cannot
parallelize the AES operation of PNE with that of AEAD (see
https://github.com/openssl/openssl/blob/OpenSSL_1_1_0h/crypto/aes/asm/aesni-x86_64.pl#L24-L39
about the impact of parallelization).

I do not think that 2% to 4% of additional overhead to the crypto is an
issue for QUIC/HTTP, but current overhead of 10% is something that we might
want to decrease. I am glad to be able to learn that now.


2018-06-22 5:48 GMT+09:00 Nick Banks <nibanks=[e-mail]
>:

> Hello QUIC WG,
>
>
>
> I recently implemented PNE for WinQuic (using bcrypt APIs) and I decided
> to get some performance numbers to see what the overhead of PNE was. I
> figured the rest of the WG might be interested.
>
>
>
> My test just encrypts the same buffer (size dependent on the test case)
> 10,000,000 times and measured the time it took. The test then did the same
> thing, but also encrypted the packet number as well. I ran all that 10
> times in total. I then collected the best times for each category to
> produce the following graphs and tables (full excel doc attached):
>
>
>
>
>
> *Time (ms)*
>
> *Rate (Mbps)*
>
> *Bytes*
>
> *NO PNE*
>
> *PNE*
>
> *PNE Overhead*
>
> *No PNE*
>
> *PNE*
>
> *4*
>
> 2284.671
>
> 3027.657
>
> 33%
>
> 140.064
>
> 105.692
>
> *16*
>
> 2102.402
>
> 2828.204
>
> 35%
>
> 608.827
>
> 452.584
>
> *64*
>
> 2198.883
>
> 2907.577
>
> 32%
>
> 2328.45
>
> 1760.92
>
> *256*
>
> 2758.3
>
> 3490.28
>
> 27%
>
> 7424.86
>
> 5867.72
>
> *600*
>
> 4669.283
>
> 5424.539
>
> 16%
>
> 10280
>
> 8848.68
>
> *1000*
>
> 6130.139
>
> 6907.805
>
> 13%
>
> 13050.3
>
> 11581.1
>
> *1200*
>
> 6458.679
>
> 7229.672
>
> 12%
>
> 14863.7
>
> 13278.6
>
> *1450*
>
> 7876.312
>
> 8670.16
>
> 10%
>
> 14727.7
>
> 13379.2
>
>
>
> I used a server grade lab machine I had at my disposal, running the latest
> Windows 10 Server DataCenter build. Again, these numbers are for crypto
> only. No QUIC or UDP is included.
>
>
>
> Thanks,
>
> - Nick
>
>
>



-- 
Kazuho Oku