3 ms·
It also makes hardware offloads like TSO and LRO impossible, and increases cost-per-byte served by a factor of 4 or more. So if you have infinite CPU to throw
by drewg123 7y ago
It also makes hardware offloads like TSO and LRO impossible, and increases cost-per-byte served by a factor of 4 or more. So if you have infinite CPU to throw at QUIC and/or low bandwidth or connection targets, its great. If you are concerned at all about server-side efficiency, its terrible.
FWIW, I work on the Netflix CDN, and specialize in server-side efficiency; we have had 100G flash CDN nodes for years serving at 90G+ in production. None of that would be possible with QUIC as it stands. I suspect our max B/W on these machines would drop from ~95Gb/s to 20Gb/s or less if we were to switch to QUIC.
- scott00 7y agoDoes the protocol actually make it impossible, or is it just not implemented by current OS/hardware?
- vlovich123 7y agoDefinitely just that the HW hasn't caught up. https://www.netdevconf.org/0x13/session.html?talk-quic-offload https://www.netdevconf.org/0x13/session.html?talk-quic-offlo...
- api 7y agoI hear you and those are valid points. Don't blame QUIC. Blame ISPs and middlebox makers for abusing their (literal network-wise) position and breaking the end-to-end principle. History has shown that we just have to encrypt everything and quite literally cut out the middleman/box.