Last July, I attended IETF 126 in Vienna (Austria). As a PhD student and academic researcher, my primary objective is to get feedback from industry professionals on our work. People often don’t realize that a single piece of information about real-life network deployments can lead to research papers. For us, events like the IETF are a gold mine.

During my PhD, I have been working on extending QUIC and its multiple-path extension to support flexible multicast delivery: Flexicast QUIC. While the design is (subjectively) neat, it requires the whole Multipath QUIC machinery to work. On the other hand, several features of this multipath extension are not needed for flexicast: path probing, per-path nonce computation, …

To push the “adoption” (not strictly in the IETF sense, but to motivate people to work with it for their use case) of Flexicast QUIC, we wondered whether Multipath QUIC could be removed from the design. Of course, we would reinvent some parts, but how much, exactly?

mumuQUIC: micro Multicast in QUIC

We came to the IETF hackathon with a simple objective: determine the minimal set of features we need to add to QUIC to enable working multicast delivery in the protocol. This reflection led to mumuQUIC, standing for micro-multicast QUIC. In only ~320 lines of text, we describe a minimal extension that delivers unreliable data (DATAGRAM frames) efficiently over multicast in QUIC! In less than 1.5 days of work, the participants implemented mumuquic in six different QUIC stacks, including Cloudflare quiche, Quinn, aioquic, and quic-go.

As a proof-of-concept application, I used the FFmpeg toolkit to generate an RTP stream from my webcam and delivered it over mumuQUIC datagrams. Participants could then receive the RTP stream either through GStreamer or custom RTP parsers once the mumuQUIC DATAGRAM frames were processed. For example, the photo below shows the stream displayed on a computer and on two smartphones running mumuQUIC.

Oh, and what was the medium? Multicast Wi-Fi! Yes, this is true. Ok, not really… I mean… Multicast-to-unicast conversion, to be precise. But we used the IETF hotel Wi-Fi network to transmit the video frames efficiently, and it worked!

QUIC Working Group presentation

Finally, we presented this result at the QUIC working group meeting a few days later — I thank Lucas Pardue (chair of the WG) again for giving us time to do so—accompanied by Max Franke, another researcher from TU Berlin, also working on Multicast extensions for QUIC. The community feedback was very positive, and it finally led to a (non-WG-forming) Bird of Feather (BoF) for IETF 127 in San Francisco!

Great news; I will keep you informed.