QUIC would have the advantage that you could maintain that one stream and multiplex both video data and control information over it without the problems you'd encounter doing so on HTTP/1.1 or HTTP/2, but that definitely isn't worth the performance loss you'd get by deploying it today.
I think it makes perfect sense for you to wait for QUIC to be more heavily optimized. Once optimized, I think QUIC has the potential to be even faster, but it isn't there yet for your use case. (For that matter, some of that optimization is work you've put into optimizing existing HTTP and TCP, so it isn't surprising that your existing optimized stack beats current QUIC.)
[1]: https://mailarchive.ietf.org/arch/msg/quic/OnBhC4gCosmlU3VKo...
Whilst QUIC shines when you have a lot of small assets that you want to fetch as quickly as possible?
Like could we have a system where we choose http 2 or 3 depending on the type of data?
The way video is generally served now is actually as a large number of dynamically-selected chunks of the video and associated audio. QUIC makes perfect sense for YouTube/Netflix/Vimeo type VOD, and especially the MPEG-DASH style of streaming.
It seems a bad reason to knock the protocol cos people haven’t implemented something unrelated (hardware acceleration) for it.
I appreciate it obviously would be stupid for you to switch given those stats. But it’s not related to the protocol design or some fundamental shortcoming with QUIC.
Do you mean to say “YT does JIT transcode” or simply that the huge long-tail corpus means that transcode optimization >>> delivery benefits? :)
Other things to factor in: different mix of mobile users & geographies (incl. access networks), software stacks, hardware costs/goals/footprint, etc.
Indeed. I work at Netflix on optimizing cpu efficiency on our Open Connect CDN nodes, largely to reduce power use and capital expenses. We use FreeBSD, ngnix & TCP, and make heavy use of offloads like async sendfile(), TSO, LRO, kTLS and more recently hardware kTLS offload.
Right now, I have a single socket 32c/64t AMD Rome server delivering over 350Gb/s of real Netflix customer traffic. This traffic is all TLS encrypted, and is served across hundreds of thousands of TCP connections.
From measurements we've done, current QUIC would cost about 3x as much as TCP when using software crypto. So my back-of-the-envelope guess is that this box would do about 77Gb/s with QUIC (230Gb/s is the limit when disabling hardware TLS offload and using software crypto).
Are the benefits of QUIC really worth an a 4x increase in the amount of energy required per stream?
Once QUIC has optimizations similar TCP in place, the story will obviously be different. But we're not there yet.