SYSTEMS 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 important 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 important 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.

A CDN For Real-Time Streams

What MoQ aims to do is offer latency closer to that of WebRTC with the scalability to support massive numbers of receivers that comes with DASH. The key to scalability in MoQ is the use of relays, a form of overlay that handles replication of media. Just as CDNs can scale the delivery of HTTP traffic, MoQ relays are designed to scale the delivery of MoQ traffic. They do so by supporting a publish/subscribe model for media distribution.  In MoQ, the main abstraction is a track, which might, for example, correspond to a particular live stream encoded at some resolution. Publishers publish media to the track and subscribers receive it. With relays sitting between publishers and subscribers, the two groups don’t need to have direct connections or even know about each other.

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 example, 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 important packets are not stuck waiting for less important ones to arrive.

MoQ relay nodes can store, forward, and replicate objects. They don’t need to have any understanding of the content; objects are self-contained pieces of data that carry enough metadata, which is visible to relays, to enable them to be handled appropriately. A typical object in MoQ would be an independently decodable set of frames in a video. The metadata allows the relay nodes to make decisions about how to prioritize transmission of objects in the event of congestion or other resource shortage. Metadata also enables subscribers to determine what track an object belongs to.

Application Layer Framing Lives On

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. ®

Larry Peterson and Bruce Davie are the authors behind Computer Networks: A Systems Approach and the related Systems Approach series of books. All their content is open source and available for free on GitHub. You can find them on Mastodon, their newsletter right here, and past The Register columns here.