3 ms·
In estimates I've done, in its current un-accelerated state, it would at least triple the CPU cost per byte served on our CDN workload. We basically lose: - s
by drewg123 7y ago
In estimates I've done, in its current un-accelerated state, it would at least triple the CPU cost per byte served on our CDN workload. We basically lose:
- sendfile
- ktls
- TSO
Its like stepping into a time machine and going back to the mid 90s. To send data with QUIC, we have to get byes from kernel into userspace, encrypt them in userspace, and then write them back to the kernel, where they travel down to the NIC an MTU at a time. Ugh.
- mikepurvis 7y agoIt doesn't exist today, but there's nothing preventing a kernelspace implementation of sendfileq (or whatever), is there?
- xakahnx 7y agoOne of the consequences of TCP being implemented in the Linux kernel is that companies were implicitly motivated to open source any performance or efficiency improvements to their TCP stack. Are any companies collaborating to improve QUIC efficiency issues in open source? The issues are well understood among at least the big cloud providers.
- RMPR 7y agoQuic is being standardized in the IETF there are a couple of companies involved: - Cloudflare - Facebook: They already use QUIC for some of their products, or at least it's a pretty sensitive piece of software on their architecture because they ask to report bugs to the bug bounty program[1] - Microsoft - Nginx - Google - NetApp - Mozilla - Traffic Server - Litespeed - Fastly - F5 - Apple Amazon is very quiet about all that, but they are probably looking into it. So, it is pretty backed up. If you take a look at their workgroup homepage (quicwg.org) you will see a couple of open source implementations, some from those same companies. [1]: https://github.com/facebookincubator/mvfst/blob/master/README.md https://github.com/facebookincubator/mvfst/blob/master/READM...