Who is this for and what problem do they have today?
Enterprises that are required to do encryption on data transport are introduced with CPU overhead.
Current Kernel TLS implementations on both Linux and FreeBSD claim, reducing one hop of copying socket bytes from user-space to kernel-space improve latency for TLS communication.
When data is encrypted in order to transfer it on wire, zero-copy benefits are lost, Kernel TLS helps in this case.
What are the success criteria?
Successfully reducing 99th percentile latency by around %10-20 on TLS connections that are constructed by symmetrical AES-GCM ciphers.
Why is solving this problem impactful?
Kernel TLS is relatively easy to implement when compared to benefits that are gained.
Additional notes
Only AES-GCM ciphers are currently supported
Supported platforms are limited
Should be an opt-in configuration
It is not possible to implement Kernel TLS with pure Java, it requires setting socket options on unix file descriptor. However workaround is still there with JNA/JNI.
Which Redpanda can easily out-compete JVM implementation
omersiar
commented
1 year ago
Who is this for and what problem do they have today?
Enterprises that are required to do encryption on data transport are introduced with CPU overhead.
Current Kernel TLS implementations on both Linux and FreeBSD claim, reducing one hop of copying socket bytes from user-space to kernel-space improve latency for TLS communication.
When data is encrypted in order to transfer it on wire, zero-copy benefits are lost, Kernel TLS helps in this case.
What are the success criteria?
Successfully reducing 99th percentile latency by around %10-20 on TLS connections that are constructed by symmetrical AES-GCM ciphers.
Why is solving this problem impactful?
Kernel TLS is relatively easy to implement when compared to benefits that are gained.
Additional notes
https://netdevconf.info/1.2/papers/ktls.pdf
JIRA Link: CORE-1376