QUIC and Multicast

On a multicast-capable network, a sender can transmit common data once for delivery to many receivers. Bringing that model to QUIC means adapting a transport built around individual connections. Two proposals, Multicast QUIC and Flexicast, approach the problem from different starting points. Their recent evolution points toward a common foundation: Multipath QUIC.

That convergence gives shared delivery a place within QUIC’s connection model and a route back to unicast when needed. It also leaves a question of scope: which mechanisms must the transport provide, and which policies should applications choose?

QUIC started with two endpoints

In QUIC’s original design, a connection belongs to one client and one server. They exchange transport parameters and establish secrets through a TLS handshake. Streams, acknowledgments and flow-control limits describe communication within that individual relationship. QUIC version 1 supports moving a connection between network paths. Concurrent data delivery over several paths requires an extension. ¹

Multicast changes the assumptions. A sender wants one packet to be useful to an entire group, whose members can have different receive limits and loss histories. An application-data packet protected for one ordinary QUIC connection cannot simply be copied to every other connection and decrypted there. Shared delivery needs its own protection context, while feedback and receiver-specific decisions still need a return path. ¹²

Multipath QUIC supplies part of the missing structure. It lets one connection use several paths and allows data lost on one path to be retransmitted on another. It remains a transport between two endpoints; the multicast proposals adapt that path model to a delivery path shared by many connections. ²

Two approaches to shared delivery

Multicast QUIC, or MCQUIC, adds shared channels alongside individual unicast connections. Its earlier architecture already treated a channel as an alternate delivery route, with a channel identifier, a separate packet-number space and multicast-specific acknowledgments. It also defined explicit controls for announcing channels, distributing keys and directing receivers to join or leave. ³

Flexicast starts explicitly from Multipath QUIC. Its first draft, published in October 2024, proposed combining individual unicast paths with a shared multicast path. Each receiver keeps its private connection to the sender; the group receives common packets protected with separate shared keys. ⁴

Flexicast receivers return feedback over unicast using Multipath QUIC’s PATH_ACK. Lost data can be retransmitted to the group or to a particular receiver. Revision 03 also supports encrypting a common packet once and replicating it to unicast destinations, saving repeated encryption while still sending a separate copy to each destination. ⁴

Currently, MCQUIC and Flexicast are individual Internet-Drafts targeting Experimental publication. Neither has working-group adoption or RFC status. ³⁴

Multicast QUIC moves toward multipath

MCQUIC revision 08 described its channel machinery largely as an extension to QUIC version 1. It mentioned possible reuse of a multipath acknowledgment format, but did not contain the explicit multipath integration section now present in revision 09. ³

Revision 09 describes each multicast channel as an additional Multipath QUIC path from the receiver’s perspective. The unicast connection stays open, and data can arrive through either route, supporting unicast fallback and retransmissions. Shared-path keys differ from the private connection’s keys, and receivers cannot send on the multicast path. ³

This brings MCQUIC closer to Flexicast’s original architecture, although the protocols remain distinct. Revision 09 leaves path initiation unresolved: must the client initiate the new path, or should Multipath QUIC permit the server to do so? ⁴³

Path selection can remain within the transport, while applications still need compatible stream layouts and a policy for late joiners. MCQUIC requires coordinated stream identifiers across receivers. A receiver joining an ongoing stream needs the preceding data from offset zero before it can consume later bytes; the sender can provide unicast catch-up or begin a new stream. ³

Multicast QUIC complexity and the MoQ parallel

Both proposals must manage membership, receiver limits and shared keys. MCQUIC revision 09 defines nine new frame families, including MC_ACK. Flexicast revision 03 defines three: FC_ANNOUNCE, FC_STATE and FC_KEY, with acknowledgments handled through PATH_ACK. These counts describe how the controls are organized; the protocols do not yet offer equivalent guarantees. ³⁴

MCQUIC separates joining, leaving, state reporting and retirement. It also limits the aggregate multicast rate, the number of channel identifiers a receiver tracks and its simultaneous memberships. A join references versions of the receiver’s limits, channel state and key, requiring implementations to reconcile changes that can arrive at different times. Its MC_INTEGRITY frames authenticate shared packets using hashes whose trust ultimately comes from the authenticated unicast connection. Possession of the group key alone cannot establish the sender’s identity. ³

Flexicast aggregates acknowledgments across receivers and respects the most restrictive active flow-control limits. Its key-update section remains unfinished, and stronger sender authentication is deferred: a receiver with the shared key could forge traffic if it can spoof the sender’s address. Its smaller control protocol therefore does not demonstrate equivalent security with less implementation work. ⁴

Even an application delivering one common stream must coordinate membership, receiver limits and key changes. The design question is which mechanisms every implementation needs, and which could be optional. The versioned join procedure gives a concrete example of the work involved: implementations must account for a receiver whose limits have changed or whose key update has not yet arrived.

Congestion control also needs rules specific to group delivery. A shared transmission can reach receivers with different bottlenecks, so reusing Multipath QUIC does not settle how the sender should adjust its rate or move a receiver to unicast. MCQUIC describes hybrid multicast-unicast congestion control as experimental. Flexicast outlines alternatives involving multiple delivery rates, adaptation to receiver feedback and removal of receivers that cannot sustain a minimum rate. These choices remain part of the design work. ³⁴

MoQ raises a similar question of scope at the application layer. Media over QUIC Transport defines a content hierarchy, subscription and fetch operations, and relay behavior for caching and distribution. Non-relay endpoints can implement the subset they need, while relays must implement every message and the relay processing rules. A simple endpoint therefore need not bear the full relay implementation burden. MoQ’s content groups and MCQUIC’s network channels serve different purposes; the useful parallel is how each design divides responsibilities among participants. ⁵

Both efforts have been under development for several years. MCQUIC’s first draft appeared in May 2022; MoQ Transport’s first working-group draft appeared in July 2023. They both remain drafts, at different stages and with different publication goals. That matters to implementers seeking a stable specification. ³⁵

The IETF’s process description recognizes that technical review, testing and public discussion require significant time and effort. ⁶ The design concern is that more interacting requirements can expand the work needed to reach agreement and verify interoperability. Participants targeting different workloads may also disagree about which requirements belong in the common protocol.

What the next revisions need to resolve

The next revisions need to resolve concrete questions. MCQUIC must settle who initiates the shared path. Flexicast must specify key updates and address its deferred sender-authentication work. Both need to refine how congestion control governs shared delivery and unicast fallback. Implementation experience can test how those rules interact with membership changes and receiver limits. ³⁴

The specifications should also distinguish mandatory transport behavior from application policy. Security and congestion safety need complete common rules. Applications should have room to choose recovery budgets, retention periods and completion policies, with agreed semantics wherever those choices affect interoperability. A software distributor waiting for every receiver and a live feed discarding stale data need different policies even when they share the same delivery mechanism.

A shorter specification can reflect a narrower solved problem. The opportunity in multicast QUIC’s evolution is to agree on that common problem, then use implementation experience to establish which additional coordination belongs in the transport.

References