←back to thread

The first Media over QUIC CDN: Cloudflare

(moq.dev)
292 points kixelated | 1 comments | 22 Aug 25 18:24 UTC | HN request time: 0.204s | source
Show context
englishm ◴[22 Aug 25 19:11 UTC] No.44988596[source]▶
Hi! Cloudflare MoQ dev here, happy to answer questions!

Thanks for the award, kixelated. xD

replies(6): >>44989011 #>>44989230 #>>44989615 #>>44989828 #>>44990875 #>>45005783 #
ddritzenhoff ◴[22 Aug 25 22:50 UTC] No.44990875[source]▶
Hi, I've got one.

Does your team have any concrete plans to reduce the TCP vs. QUIC diff with respect to goodput [1]? The linked paper claims seeing up to a 9.8% video bitrate reduction from HTTP/2 (TCP) to HTTP/3 (QUIC). Obviously, MoQ is based on a slightly different stack, so the results don't exactly generalize. I can imagine the problems are similar, though.

(I find this stuff fascinating, as I spent the last few months investigating the AF_XDP datapath for MsQuic as part of my master's thesis. I basically came to the conclusion that GSO/GRO is a better alternative and that QUIC desperately needs more hardware offloads :p)

[1]: https://arxiv.org/pdf/2310.09423

replies(2): >>44991298 #>>44993984 #
1. johncolanduoni ◴[22 Aug 25 23:40 UTC] No.44991298[source]▶
QUIC implementations are definitely not tuned well in practice for 600Mbps flows on low latency, low loss networks, as the paper attests. But I don’t think almost any uses of video streaming fit that bill. Even streaming 4K video via Netflix or similar is tens of Mbps. In general if you don’t have loss or the need to rapidly establish connections, QUIC performance is not even theoretically better, let alone in practice.

P.S. if there’s a public link to your masters thesis - please post it! I’d love to read how that shook out, even if AF_XDP didn’t fit in the end.