Flexicast QUIC over a real network

We are running a demonstration of Flexicast QUIC (FCQUIC)^[1], an extension of QUIC and Multipath QUIC that allows one source to deliver the same content to many receivers over multicast, and fall back to unicast for receivers that in unicast only networks. The source run in the UCLouvain network, and is connected to the GEANT network through Belnet. GEANT has native multicast connectivity, but also provides AMT relays, which allows clients in non multicast networks to setup AMT tunnels and receive multicast content by relying on replication on the relay. Run a receiver by following the instructions to help us gather insights into Flexicast QUIC deployments over real networks.

Why

Interest in IP multicast is rising again, largely surrounding massive video live streaming, file downloads (such as video games) ^[2]^[3], and uses in AI datacenters^[4]. IP multicast saves a lot of bandwidth when many receivers want the same data, but inter-domain deployments suffered from pricing and deployment difficulties. Existing reliable multicast transports assume an all or nothing scenario, wherein an application either transmits all of its content over multicast, or none at all. The chicken-or-the-egg problem has also plagued multicast deployments, where large scale multicast deployments do not exist due to the lack of applications requiring it, which in turn never develop due to the lack of usable deployments^[5].

Flexicast QUIC attempts to solve this issue by relying on multicast as the main transfer channel, but also using unicast connections for retransmissions, control messages, and as a backup transfer channel for receivers in non multicast networks. This demo goes a little bit further, we extended FCQUIC to support fallback to AMT tunnels, which handle tunnel creation and byte replication on the relay. This allows the source to send its data once to a group of receivers whose reception mode may either be multicast or unicast through AMT tunnels. Several AMT relays are located in the GEANT network, so native multicast replication is still happening inside of the network whenever clients from different regions connect to the source.

How it works

Each receiver opens a normal, encrypted QUIC connection to the source. This unicast path carries control traffic, acknowledgements and retransmissions.
The source announces a shared multicast flow using a frame called FC_ANNOUNCE. The receiver then tries to join the source-specific multicast (SSM) group, and if the join succeeds, gets the data efficiently.
Receivers acknowledge multicast packets on their own unicast path with the source. The source retransmits lost packets over unicast when a few receivers lost them, or over the flexicast flow when many did (though the latter is not currently implemented).
When the multicast flow is idle, the source transmits FC_PING frames over it, so that receivers can detect broken or non functional multicast connectivity. The interval at which these frames are sent is announced in the FC_ANNOUNCE frame, and receivers set the threshold for broken multicat connectivity at three times this interval.
If multicast packets never arrive after a join, or stop, the receiver opens an AMT tunnel (Automatic Multicast Tunneling RFC7450) to an AMT relay in the GEANT network, which allows it to receive the multicast packets from the GEANT network, encapsulated in UDP.

The demo

Source

The source server is located in the UCLouvain network, connected via a GRE tunnel to Belnet, the belgian education network operator, which has multicast connectivity with the GEANT network.

There are two FCQUIC sources running, one with QUIC's PING frames sent on the multicast flow every 250ms, however this frame is ack-eliciting, which induces load on the source at high receiver counts. TheFC_PING frame was therefore introduced, which is by default non ack-eliciting, but may carry information to identify a group of receivers that the sources wants to obtain ACKs for. The demo receiver uses the FC_PING source. But you may run the PING receiver with the :ping tag. The picoquic container will also connect to the PING source.

Multicast fallback for receivers in non multicast networks

Multicast connectivity with the GEANT network is possible at universities in Europe, but is unlikely in most case. Thankfully, GEANT has a set of AMT (Automatic Multicast Tunneling RFC7450) Relays that enable clients in non-multicast networks to create on-demand unicast tunnels to receive multicast content.

Our demonstration makes use of these relays to provide client initiated multicast fallback to AMT if the client notices it isn't receiving multicast data natively. This is parallel to the unicast fallback offered by Flexicast QUIC, in which a client that doesn't meet the group's minimum network quality is evicted and receives content through unicast only. This unicast fallback is also applicable for clients in non multicast network, but the latter use case not in use in this demonstration in order for the source to distribute all of its content via multicast, and rely on the network to reach clients, wherever they are.

The AMT relays in the GEANT network all advertise the Anycast address62.40.96.44.

Run a receiver

Latest updates

Two sources are running! 2026-11-13

References

L. Navarre, Q. De Coninck, T. Barbette, and O. Bonaventure, “Taking the Best of Multicast and Unicast with Flexicast QUIC,” SIGCOMM Comput. Commun. Rev., vol. 55, no. 2, pp. 2–12, Jul. 2025.
McGill, “Using multicast for large-scale live streaming over the Internet,” IETF 124 MOPS side meeting, 2025.
S. A. (BT), “Multicast-assisted unicast delivery,” IETF 123 MOPS, 2025.
J. Zhang, W. Cheng, and K. Liu, “Requirements and Gap Analysis of Multicast in AI Data Centers,” Internet-Draft draft-zhang-rtgwg-multicast-requirements-gaps-aidc-01, Mar. 2026, work in progress.
L. Navarre and O. Bonaventure, “Towards an Internet Deployment of Flexible Multicast QUIC,” in Proc. ACM SIGCOMM 2025 Posters and Demos, Coimbra, Portugal, Sep. 2025, pp. 137–139.