RE: Packet number encryption

[Praveen Balasubramanian <[e-mail]>]

Makes sense. The 1%+ overhead I had quoted was in comparison to full protocol processing all the way from app to NIC. This is with an unoptimized early QUIC implementation and not fully optimized UDP/IP stack (we have focused much much more on optimizing TCP in the past). After software stack optimizations, the crypto share of the cost will only keep going up for which we have no technique other than to offload when such support is available in hardware and offload is way more challenging when workload is hosted in VMs and containers.

From: Mikkel Fahnøe Jørgensen [mailto:[e-mail]]
Sent: Saturday, February 10, 2018 3:36 AM
To: Victor Vasiliev <[e-mail]>
Cc: Praveen Balasubramanian <[e-mail]>; [e-mail]; Marten Seemann <[e-mail]>; huitema <[e-mail]>
Subject: Re: Packet number encryption

To put numbers into perspective using Intel 2015 data

https://software.intel.com/en-us/articles/improving-openssl-performance#_Toc416943490<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsoftware.intel.com%2Fen-us%2Farticles%2Fimproving-openssl-performance%23_Toc416943490&data=04%7C01%7Cpravb%40microsoft.com%7C947ea96d592c498130df08d5707a6db1%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636538593507129957%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=I1%2BnvvFBfsQ1P%2BwSI7riWr%2FkP9ydkAihxlpAgpFggEg%3D&reserved=0>

A 64 byte message in AES-GCM AEAD in HW would use 1.03 cycles per byte or 66 cycles total, or 22ns on a 3GHz core.

For packet numbers we use the CBC encrypt numbers because here AES cannot exploit block parallelism.
Here we see 4.44 cycles/byte in HW or 71 cycles per block. With a 3GHz setup that would amount to about 24ns overhead for packet encryption.

Clearly it makes no sense that AES-GCM is faster than a single AES block encryption, but these are only approximate numbers and CBC mode might have a little overhead, so we clamp packet numbers to 22ns.

Taking the 98ns overhead by the Solarflare report we get a total (simplified) processing time is 98ns non-crypto, 22ns for packet number, and 22ns for AEAD totalling 142ns. So the packet number encryption overhead would be 22/(98+22)*100% = 18%. The numbers ignore other QUIC bookkeeping, but that can be done in other cores or outside the latency critical window.

This does not take into account that AEAD operation may operate less than optimal because the packet number must be extracted first. On the other hand, it is also not a disastrous overhead if no good alternative can be found.

Earlier AES-NI I’ve seen from Intel doc suggests around 100cycles in HW for a single AES-128 block which would be 33ns per packet number in the above example.


On 10 February 2018 at 06.18.25, Mikkel Fahnøe Jørgensen ([e-mail]<mailto:[e-mail]>) wrote:
98ns for 68 byte messages