Large-scale one-to-many events occur when many people want the same content at the same time. Historical use cases included IPTV, but while video-on-demand (VoD) applications rose in recent decades, demand for live streaming and large-scale software updates also increased significantly. One can think of the very recent (at the time of writing this blog) Grand Theft Auto 6 trailer, which Netflix released for only a few hours and which crashed the platform due to high demand. And we are not even talking about downloading the game, which should weigh more than 150 GB. More examples of this have emerged in recent years, including live-streaming sports events, Fortnite, and software updates.

These demand spikes require network operators to shape their networks accordingly, creating an over-provisioning paradox: most of the time, networks have unused bandwidth, which is used only for these sporadic, large-scale one-to-many events. In his thesis, Louis Navarre explored this paradox in two different scopes.

Network-layer Forward Erasure Correction

First, this spare bandwidth can improve quality of service by using Forward Erasure Correction (FEC) methods. FEC techniques encode sent data, producing more output symbols so a receiver can recover from packet losses without packet retransmissions. Such mechanisms usually apply at the data link and transport layers, e.g., in the QUIC protocol. However, adoption requires standardization and consumes additional processing on end hosts. As a first contribution, this thesis aimed to provide such FEC capabilities as a service from within the network. Powered by IPv6 Segment Routing network programming, these FEC tunnels can be dynamically deployed.

Because network-layer work can require high-speed processing, this work focused on a rigorous software implementation starting from FastClick, achieving more than 60 Gbps of protected traffic under heavy losses (3%), as illustrated in the figure below.

Emulation is fine, but a real experiment is better. We evaluated our system over the Starlink network, which is known to expose non-congestion-induced packet losses — which can be recovered using FEC. The thesis presents numerous results showing that the approach improves the quality of service for latency-sensitive applications.

Flexicast QUIC: “In the end, it is all about multicast.”

The core contribution of this thesis focuses on why we need over-provisioning: content providers (e.g., CDNs) currently use unicast to distribute the same data to numerous receivers. A more elegant solution is to rely on multicast protocols. As illustrated below, multicast communication relies on the underlying network to efficiently replicate a single packet emitted by the source to all intended receivers. With multicast, at most a single copy of each packet flows in the network, making it an efficient delivery method. Despite this, multicast is rarely deployed in practice because of numerous problems.

This thesis focuses on a subset of these problems at the transport layer. With its modern features and large deployment (around 30% worldwide), QUIC is a natural candidate for solving some of these problems, but not all. Multipath protocols have also emerged since researchers last considered multicast transport. In this work, we reconsidered multicast as a multipath problem, resolving numerous issues.

The outcome of this idea led to Flexicast QUIC (FCQUIC), standing for flexible multicast. As shown below, FCQUIC exposes a per-receiver bidirectional unicast path and a shared unidirectional multicast flow. The multicast flow efficiently conveys data to receivers (e.g., using an IP Multicast network below), while the individual unicast paths ensure reliability and robustness to failures or underperforming receivers; for example, bottleneck receivers can fall back to unicast to avoid degrading multicast communication.

The neat thing is that the transition between unicast and multicast is seamless for the receivers, as they view the multicast flow as another multipath path. As such, unicast fallback, retransmissions, … are just multipath problems which have already been solved in the past.

We implemented Flexicast QUIC in Cloudflare quiche, aiming for scalability: a single server could sustain (at least) 1000 receivers for a cumulated throughput of ~80 Gbps. We also considered bottleneck receivers, showing that a simple algorithm could detect them and fall back to unicast, improving the quality of experience for the other receivers in the group.

In a second step, we tackled the ACK implosion problem in multicast: a single data packet triggers as many acknowledgments as there are receivers. By knowing the exact number of active receivers, an FCQUIC source can dynamically advertise and update an acknowledgment delay that receivers use to pace their PATH_ACK frames. Not only does this mechanism work, but we also studied its impact on the scalability of the Flexicast QUIC server: CPU usage (assuming it reflects the workload) is primarily influenced by the acknowledgment rate, which we can control with our mechanism. This result lets us consider, at least theoretically, deployment at a larger scale than we could achieve with our limited setup. This chapter also allowed us to consider the problem of loosely synchronized receivers for file delivery (think about these Fortnite updates).

The Optimistic Acknowledgment (OACK) attack

I will not explain how we found ourselves working on this topic, but we did. The Optimistic Acknowledgment (OACK) attack is an attack where an end host (let us consider it the client) sends acknowledgments for packets not (yet) received, forcing its peer (the server) to increase its sending rate, and ultimately leading to Denial of Service attacks.

Think about the CUBIC congestion control algorithm: the only way CUBIC reduces the congestion window is after the detection of packet losses. By sending these OACKs, the client hides potential losses from the server, which can indefinitely increase its sending rate until it saturates its own network. The interesting point is that, because QUIC packets are mostly encrypted (and the ACK frames along with them), middleboxes cannot investigate the ACK contents before they reach the server.

Section 21.4 of RFC 9000 describes a way to detect the attack by randomly skipping packet numbers. If the client cannot guess these skips, it will eventually send an ACK frame for this skipped packet number. Because packet numbers are unique and monotonically increasing during the connection lifetime, this should never happen. In this chapter, we do not revoke this mechanism—it works—but investigate whether QUIC implementations support the feature.

We took the 16 available QUIC server implementations from the QUIC Interop Runner, and found that 11 of them did not skip packet numbers, and are exposed to the attack. The next step was to produce the attack, but we needed an OACK predictor. The good news is that a very simple algorithm did the trick, and we managed to attack these 11 implementations: they all ended up sending faster than they should. We also attacked a real CDN, with its explicit agreement, and showed that it was vulnerable to the attack.

This work led to discussions with the maintainers of the vulnerable implementations, and most of them patched their stack with the feature, including those from Alibaba, Meta, Microsoft, Cloudflare, …

Wrapping it up

Louis Navarre presented these results in his PhD thesis: Improving the Efficiency and Flexibility of Network Communications, which he successfully presented on August 26th, 2026. This thesis is just one of many contributions needed to solve multicast’s historical problems. We just focused on transport-layer issues (and not all of them). More work is needed if we aim to deploy multicast at the Internet level. At the end of the thesis, we discuss ideas to extend this work, but we hope this contribution is just the first of many more to come.

Stay tuned at the IP Networking Lab!

Photo