Media Over QUIC can scale real-time streaming and carry the world's vids is attracting attention across the tech world. Analysts, enthusiasts, and industry observers are watching closely to see how this story develops.
This update adds another signal to a fast-moving sector where product decisions, platform changes, and competition can quickly shape the market.
The low latency of WebRTC, the scalability of DASH, and perhaps no need for CDNs
platformS APPROACH A few weeks ago, Larry and I independently received the same advice from two different sources: take a look at Media Over QUIC (MoQ) for your next edition. I’ve been following the standardization of QUIC for several years (and wrote about it) but MoQ had not yet come onto my radar. A quick look at some IETF drafts gave me some of the main concepts, but it can be frustratingly hard to pick out the significant high-level ideas from the masses of protocol-specific detail that goes into an Internet draft. And there are enough moving parts to MoQ for it to present another case of the blind men and the elephant. I’m going to explain what I think is significant about MoQ in this post.
For one thing, the name doesn’t get across what is interesting to me about MoQ. Yes, it can be used to transmit media (e.g., video and audio) using QUIC as the underlying transport protocol. But you can do that today just by watching a video on the web if the server happens to support HTTP3 over QUIC. There is something else going on with MoQ. In my view, MoQ occupies a middle ground between WebRTC (which is used for lots of video conferencing applications like Google Meet) and DASH (Dynamic Adaptive Streaming over HTTP) which powers most entertainment video streaming on the web. If I take some of the proponents of MoQ at face value it could replace both those technologies, but more realistically I can see it filling a gap when neither DASH nor WebRTC is the ideal choice.
So let me first explain the two bookends that MoQ sits between. There are two handy blogs positioning MoQ against WebRTC and DASH that helped me form the views below, so you may want to go back to the source.
WebRTC is a collection of protocols and APIs (backed by an open source implementation) that enable a real-time media stream to be established between a pair of web browsers. There are quite a few problems that need to be solved, such as getting access to the camera and audio devices, and building an end-to-end connection between two hosts that might both be sitting behind NATs and firewalls. The media is sent using RTP over UDP (usually). This all works reasonably well today as evidenced by the success of browser-based video conferencing.
Arguably the biggest weakness of WebRTC is around scale. Large conferences generally need an overlay network to replicate the video streams out to all the participants. In the case of WebRTC, the overlay nodes are called Selective Forwarding Units (SFUs). They are typically deployed by the conferencing app provider to scale out their meetings; as I understand it, there are SFU overlays for Teams, Google Meet, Zoom, etc.
DASH is the approach used to stream most non-real-time media. The standard view is that TCP is not a suitable protocol for real-time streaming, due to its strict ordering and use of retransmissions to ensure reliability, leading to potentially unbounded delay. But since most entertainment video is not strictly real-time, DASH manages to work around the limitations of TCP, leveraging TCP congestion control along with the benefits of standard web infrastructure. In particular, DASH gets to scale thanks to the existing deployment of CDNs. And as the web is starting to adopt QUIC in place of TCP for HTTP traffic, DASH gets some benefits of QUIC as well. What DASH is not really able to do, however, is deliver low enough latency to meet the needs of real-time applications. With QUIC providing reliable delivery of each chunk of video, there is still no way to bound latency.
As its name implies, MoQ uses QUIC as the underlying transport. This might seem at odds with the desire to minimize latency, since QUIC, like TCP , uses retransmission of lost packets to ensure reliable delivery. MoQ takes advantage of some of the features of QUIC to get around this. In particular, the lightweight streams of QUIC allow for independent components of a QUIC connection to proceed without being blocked by each other. So MoQ uses streams to ensure that different parts of a media stream can be sent independently of each other. One use of this is to discard the higher resolution parts of a video if necessary to deal with congestion. It is also possible to just terminate a stream if, for instance, the observed level of congestion suggests that sending this part of the media would only exacerbate congestion, or the information in the stream would arrive too late to be useful. MoQ objects have an associated priority that can be used to make decisions about which streams to transmit and which to terminate.
The lightweight streams of QUIC stake out an intermediate point in the design space between TCP and UDP. Reliable delivery can be applied selectively to individual streams, and congestion control can limit the total amount of traffic in a QUIC connection when required. Lower priority streams can be sacrificed to ensure that latency remains within bounds, congestion is avoided, and more significant packets are not stuck waiting for less significant ones to arrive.
It strikes me (thanks to a conversation with Larry) that MoQ captures the idea of Application Layer Framing (ALF) that Clark and Tennenhouse proposed in 1990. Only the application knows what data it needs to do its job, but it can frame the data in such a way that the network can help the application function. MoQ lets the application define objects that represent units of video that can be independently decoded, and prioritize those objects based on their importance (e.g., lower priority for high frequency components of the video). The relay nodes don’t have to understand the application at all—they just use the metadata to relay objects in a way that benefits the application, which isn’t something SFUs can do. This also makes MoQ more useful than IP multicast (which has the additional downside of adding complexity to the network’s core).
The specifications for MoQ are still evolving and implementations are trying to track the specifications. Nevertheless, this approach draws on the success of existing technologies such as QUIC and DASH and has the weight of major industry players behind it, so there is reason to be optimistic for its future. The implementation of the relay function in large-scale deployments (e.g., Cloudflare) indicates the industry investment in MoQ. It also suggests that the idea of trying to replicate the success of CDNs for real-time streams might have traction. And if you want to see MoQ in action, you can try a demo here or here. ®
Why This Matters
This development may influence user expectations, future product strategy, and the competitive balance inside the broader technology industry.
Companies in adjacent segments often react quickly to similar moves, which is why stories like this tend to matter beyond a single announcement.
Looking Ahead
The full impact will become clearer over time, but the story already highlights how quickly the modern tech landscape can evolve.
Observers will continue tracking the next steps and how they affect products, users, and the wider market.
