QUIC L. Navarre Internet-Draft UCLouvain Intended status: Experimental O. Bonaventure Expires: 1 September 2026 UCLouvain & WELRI 28 February 2026 Flexicast QUIC: combining unicast and multicast in a single QUIC connection draft-navarre-quic-flexicast-02 Abstract This document proposes Flexicast QUIC, a simple extension to Multipath QUIC that enables a source to send the same information to a set of receivers using a combination of unicast paths and IP multicast distribution trees. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-navarre-quic-flexicast/. Discussion of this document takes place on the QUIC Working Group mailing list (mailto:quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Subscribe at https://www.ietf.org/mailman/listinfo/quic/. Source for this draft and an issue tracker can be found at https://github.com/louisna/draft-navarre-quic-flexicast. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Navarre & Bonaventure Expires 1 September 2026 [Page 1] Internet-Draft FC-QUIC February 2026 This Internet-Draft will expire on 1 September 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Flexicast QUIC . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Extensions to Multipath QUIC. . . . . . . . . . . . . . . 8 4. Handshake Negotiation and Transport parameter . . . . . . . . 9 5. Initialisation of a Flexicast Flow . . . . . . . . . . . . . 9 5.1. Flexicast Flow Announcement . . . . . . . . . . . . . . . 10 5.2. Joining a Flexicast Flow . . . . . . . . . . . . . . . . 11 5.3. Underlying (multicast) network . . . . . . . . . . . . . 13 6. Multicast flow membership management . . . . . . . . . . . . 13 6.1. Receiver-side management . . . . . . . . . . . . . . . . 14 6.2. Source-side management . . . . . . . . . . . . . . . . . 14 7. Reliability . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . 15 9. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Packet protection . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Protection Keys . . . . . . . . . . . . . . . . . . . . 17 10.2. Nonce Calculation . . . . . . . . . . . . . . . . . . . 18 10.3. Key Update . . . . . . . . . . . . . . . . . . . . . . . 18 11. New Frames . . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1. FC_ANNOUNCE frame . . . . . . . . . . . . . . . . . . . 19 11.2. FC_STATE frame . . . . . . . . . . . . . . . . . . . . . 20 11.2.1. FC_STATE actions . . . . . . . . . . . . . . . . . . 21 11.3. FC_KEY frame . . . . . . . . . . . . . . . . . . . . . . 22 11.3.1. FC_KEY algorithms . . . . . . . . . . . . . . . . . 23 12. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 23 13. Security Considerations . . . . . . . . . . . . . . . . . . . 24 13.1. Sending the TLS key secrets in FC_KEY frames . . . . . . 24 13.2. Malicious Receivers in a Flexicast Flow . . . . . . . . 24 13.2.1. Cycling Between Joins and Leaves . . . . . . . . . . 24 Navarre & Bonaventure Expires 1 September 2026 [Page 2] Internet-Draft FC-QUIC February 2026 13.2.2. Intentionally Decreasing the Flexicast Flow Performance . . . . . . . . . . . . . . . . . . . . . 24 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 15.1. Normative References . . . . . . . . . . . . . . . . . . 25 15.2. Informative References . . . . . . . . . . . . . . . . . 26 Appendix A. Existing implementation and initial results. . . . . 28 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction Starting from the initial efforts of Steve Deering [RFC1112], the IETF has developed a range of IP multicast solutions that enable the efficient transmission of a single packet to a group of receivers. In this document, we focus on Source-Specific Multicast for IP [RFC4607], but the solution proposed could also be applied to other forms of IP Multicast. Although IP Multicast is not a new solution, it is not as widely used by applications as popular transport protocols like TCP [RFC9293] or QUIC [QUIC-TRANSPORT] do not support multicast. Current IP Multicast applications include IP TV distribution in ISP networks and trading services for financial institutions. Many reasons explain the difficulty of deploying IP Multicast [DIOT]. From the application's viewpoint, a key challenge with IP Multicast is that even if there exists a unicast path between two hosts, there is no guarantee that it will be possible to create and maintain a multicast tree between these two hosts to efficiently exchange data using IP multicast. To cope with this problem, applications must implement both a multicast solution and a unicast solution. This increases the complexity and the cost of these applications. For this reason, many applications that send the same information to a large set of receivers, such as streaming services or software updates, still rely on TCP or QUIC over unicast. This is inefficient from the network viewpoint as the network carries the same information multiple times. Navarre & Bonaventure Expires 1 September 2026 [Page 3] Internet-Draft FC-QUIC February 2026 The deployment of QUIC opens an interesting opportunity to reconsider the utilization of IP Multicast. As QUIC runs above UDP, it could easily use IP multicast to deliver information along multicast trees, while offering the native reliability and security features of the protocol. Multicast extensions to QUIC have already been proposed in [I-D.pardue-quic-http-mcast] and [I-D.jholland-quic-multicast-08]. To our knowledge, these extensions have not been fully implemented and deployed. Additionally, these solutions suggest to share a QUIC connection between multiple receivers from a specific source, as well as individual connections. This design requires applications to handle two distinct connections in case of packet losses and multicast failures. Flexicast QUIC takes a different approach. Instead of extending QUIC [QUIC-TRANSPORT], Flexicast QUIC extends Multipath QUIC [MULTIPATH-QUIC]. Multipath QUIC already includes several features that are very useful to allow a QUIC connection to use unicast and multicast simultaneously. Flexicast QUIC proposes a simple extension to Multipath QUIC that enables to share an additional path between multiple receivers. The destination address of this path can be a multicast IP address and rely on a multicast forwarding mechanism (e.g., IP Multicast) to transmit the packets. This document defines the core design of Flexicast QUIC starting from Multipath QUIC. Side documents will further expand this design to add new features. This document is organized as follows. After having specified some conventions in Section 2, we provide a brief overview of Flexicast QUIC in Section 3. We describe in more details the Flexicast QUIC handshake in Section 4 and then the new QUIC frames in Section 11. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Flexicast QUIC Multipath QUIC was designed to enable the simultaneous utilization of multiple paths inside one QUIC connection. A Multipath QUIC connection starts with a regular QUIC handshake, and adds the initial_max_path_id transport parameter to negotiate the multipath extension. This parameter specifies the maximum path identifier that an endpoint is willing to maintain at connection establishment. Navarre & Bonaventure Expires 1 September 2026 [Page 4] Internet-Draft FC-QUIC February 2026 Multipath QUIC requires the utilization of non-zero connection identifiers and one packet number space per path. Multipath QUIC assumes that the additional paths are created by the client using the server address of the initial path. Consider as an example a smartphone that uses Multipath QUIC. This smartphone has a Wi-Fi and a cellular interface. The smartphone has created the QUIC connection over the cellular interface. After the handshake, the smartphone and the server have exchanged additional connection identifiers. To create a new path over the Wi-Fi interface, the smartphone sends a PATH_CHALLENGE over this path using one of the connection identifiers advertised by the server. The server replies with a PATH_RESPONSE using one of the connection identifiers advertised by the smartphone. The smartphone confirms the establishment of the second path using a PATH_RESPONSE. At this point that smartphone and the server have two paths to exchange data: the first over the cellular interface and the second over the Wi-Fi interface. Each path uses a different sequence number space, but QUIC packets are encrypted using the same connection keys using a per-path IV construct. When a QUIC packet needs to be sent, the packet scheduler selects the relevant path. If a QUIC frame is lost over one path, it can be retransmitted over any other path. Flexicast QUIC extends Multipath QUIC by using different encryption and decryption keys. As such, multiple clients can share the same additional path which is encrypted with a different key than their respective unicast path. The IP destination address of this new, shared path MAY be a multicast address, so that all receivers attached to this multicast tree receive the same packet. The case where the IP destination address is _not_ an IP multicast address is discussed later in this document. In this case, Flexicast QUIC uses packet replication at the source, e.g., using sendmmsg, using the unicast destination address of the receivers. This solution scales at the source because Flexicast QUIC generates and encrypts only one packet, and duplicating the bytes is straightforward. Navarre & Bonaventure Expires 1 September 2026 [Page 5] Internet-Draft FC-QUIC February 2026 A Flexicast QUIC connection starts with a unicast handshake, similarly to a regular QUIC connection. Receivers R1, R2 and R3 establish a connection to source S using the flexicast_support and the initial_max_path_id transport parameters. The initial path between each receiver and the source are individually secured using the keys derived at connection establishement. It remains open during the whole flexicast session and constitute a unicast bidirectional path between the source and each receiver. This path is used for two very different purposes. First, it acts as a control channel and enables the source to exchange control information with each receiver. Second, it can be used to transmit or retransmit data that cannot be delivered along the multicast tree. Most of the data sent over a Flexicast QUIC connection is transmitted along what we call a multicast flow. A multicast flow is a unidirectional multipath path from a source to a group of receivers. An important characteristic of a multicast flow is that all the packets sent by the source over this flow are secured using keys that are shared between the source and the receivers attached to the multicast flow. The source advertises the existence of a multicast flow through the FC_ANNOUNCE frame, which is sent on the unicast path with the receiver. This frame contains flow-specific information, such as the destination UDP port and IP address used by the source to send the packets, and the Flexicast Flow ID, i.e., the equivalent of the Connection ID for the multicast flow. When a receiver joins a specific multicast flow, the source additionally sends an FC_KEY frame, which contains the secret required to derive the set of TLS keys used to decrypt packets of the multicast flow. Flexicast QUIC supports two types of multicast flows. The first type multicast flow is an IP multicast tree, as illustrated in Figure 1. The source relies on an underlying IP multicast network to create an IP multicast tree and selects a set of encryption and authentication keys. The FC_ANNOUNCE frame contains the IP address of the multicast group the source uses to send the data to the receivers. The Flexicast QUIC source uses this multicast flow to efficiently send data to multiple receivers simultaneously (R1 and R2 in Figure 1). R1 and R2 use their unicast path, created at connection establishment, to return acknowledgments. A source can retransmit lost data either on the multicast flow or over a specific unicast path, e.g. when some data was missing at only one receiver. Navarre & Bonaventure Expires 1 September 2026 [Page 6] Internet-Draft FC-QUIC February 2026 Flexicast QUIC supports non-multicast-capable receivers in two different ways. A first approach is to use the unicast path to deliver the data to such receivers. This implies that each data must be authenticated and encrypted using the TLS keys derived over each unicast path. This is illustrated in Figure 1 where receiver R3 lies in a non-multicast-capable network and relies on unicast delivery. This is not efficient when there are multiple receivers. Flexicast QUIC supports a second type of multicast flow which improves performance when there are multiple unicast receivers. For these receivers, it is more efficient from the source viewpoint to encrypt and authenticate a QUIC packet using shared keys and then send a copy of this packet to all receivers, e.g. using system calls such as sendmmsg. In this case, the source maintains a multicast flow where it replicates each packet towards each receiver. It also sends an FC_ANNOUNCE frame to advertise the multicast flow, using the receiver's IP address as a destination instead of a multicast address. +----------------------------------------+ | +----------------------------+ | =======> multicast flow | | | | | | | | <------> unicast path | v 239.239.23.35:4433 v | +-> S ==============+==========> R1 | ^ \\ v | +=================> R2 | +----------------------------> R3 Figure 1: A Flexicast QUIC connection is composed of two types of paths: (1) one bidirectional, unique, unicast path between the source and each receiver and (2) a multicast flow from the source to a set of receivers relying on a multicast distribution tree Transitions between sending application data on a multicast flow and a unicast path is seamless thanks to the underlying Multipath QUIC extension. At any point in time, if the network conditions of a receiver of a multicast flow degrade, e.g., because the underlying multicast tree fails or because the receiver moves into a non- multicast network, it can leave the multicast flow and continue receiving content through its unicast path. Flexicast QUIC offers full reliability by retransmitting lost frames either to all receivers on the multicast flow, or per-receiver using their unicast path. Navarre & Bonaventure Expires 1 September 2026 [Page 7] Internet-Draft FC-QUIC February 2026 3.1. Extensions to Multipath QUIC. Flexicast QUIC modifies Multipath QUIC in three ways to enable the utilization of a shared unidirectional path, the multicast flow, as one of the Multipath QUIC paths. The multicast flow can be transported on top of an IP multicast distribution tree to reach several receivers simultaneously, which brings several challenges: 1. An IP multicast tree is unidirectional, in contrast with a Multipath QUIC path. 2. An IP multicast tree is identified by a pair . 3. All the receivers attached to an IP Multicast tree receive the same packet. Since an IP multicast tree is unidirectional, it is impossible to use the QUIC path challenge/response mechanism to create the multicast flow along an IP multicast tree. Flexicast QUIC only uses path challenge/response on unicast paths. Flexicast QUIC replaces the explicit path challenge/response from Multipath QUIC to create the multicast flow by an implicit path creation. Since the destination address of this new "path" is a multicast IP address, it is impossible for receivers to test its reachability from the source. An underlying mechanism (e.g., using IGMP) SHOULD provide feedback to the receiver on the reachability of the multicast flow through the IP multicast address provided by the source. Furthermore, the data received over the multicast flow cannot be acknowledged over this path since it is unidirectional. Because Flexicast QUIC uses Multipath QUIC, ACK frames are replaced by PATH_ACK frames. Flexicast QUIC receivers MUST send acknowledgments to the source using PATH_ACK frames sent on their unicast path. In single-source multicast, an IP multicast group is represented by the (S,G) tuple, respectively denoting the IP address of the multicast source and the multicast group. To join the multicast flow, the receivers must be informed of the (S,G) tuple of the underlying IP multicast tree. The server uses the FC_ANNOUNCE frame to advertise the identifier of the multicast tree that the receivers can join. The Flexicast QUIC packets that are sent over the multicast flow are encrypted and authenticated. However, these packets are not encrypted using the TLS keys derived during the QUIC connection establishment since they are unique to the receiver. To secure the transmission of Flexicast QUIC packets along the multicast flow, the Navarre & Bonaventure Expires 1 September 2026 [Page 8] Internet-Draft FC-QUIC February 2026 source generates an independent set of security keys and shares them using the FC_KEY frame (see Section 11.3) to all receivers over the unicast path. Since this frame is sent over the unicast paths, it is authenticated and encrypted using the TLS keys associated to each unicast path. The security questions related to the delivery of the TLS key secrets through the FC_KEY frame are discussed in Section 13.1. Section 10 gives more details on the modifications to [MULTIPATH-QUIC] to protect packets sent on the multicast flow. 4. Handshake Negotiation and Transport parameter Flexicast QUIC defines a new transport parameter, used to negotiate the use of the flexicast extension during the connection handshake, as specified in [QUIC-TRANSPORT]. The new transport parameter is defined as follows: * flexicast_support (current version uses 0xedf3): this transport parameter indicates support of the flexicast extension. The transport parameter contains two boolean values, respectively indicating support of IPv4 and IPv6 for multicast addresses. If an endpoint receives the flexicast_support transport parameter with both IPv4 and IPv6 supports set to false (0), it must close the connection with an error type of FC_PROTOCOL_VIOLATION. The support of the flexicast extension is conditioned to the support of the multipath extension, as defined in [MULTIPATH-QUIC]. As a result, endpoint wishing to support the Flexicast extension MUST support [MULTIPATH-QUIC]. An endpoint receiving the flexicast_support transport parameter from its peer, without support for multipath MUST ignore the flexicast_support transport parameter. The extension does not change the definition of the transport parameters defined in Section 18.2 of [QUIC-TRANSPORT]. 5. Initialisation of a Flexicast Flow This section details how a Flexicast QUIC source advertises multicast flows and how receivers join them. Figure 2 illustrates how a Flexicast QUIC source and receiver exchange frames on the unicast path to advertise and join a multicast flow. The handshake uses the transport parameters defined in the previous section. This handshake creates a QUIC connection between a source and a receiver. The source sends an FC_ANNOUNCE frame over this connection to advertises the multicast flow, e.g. an IP Navarre & Bonaventure Expires 1 September 2026 [Page 9] Internet-Draft FC-QUIC February 2026 multicast tree. The receiver joins the tree and then sends an FC_STATE(JOIN) frame to the source to indicate that it is attached to the tree. The source sends an FC_KEY frame containing the security keys associated to the multicast flow. The receiver returns an FC_STATE(LISTEN) frame to indicate that it receives frames over the multicast flow. Source (Unicast path) Receiver Source (multicast flow) QUIC handshake <------------> QUIC handshake FC_ANNOUNCE -------------> <------------- FC_STATE(JOIN) FC_KEY -------------> <------------- FC_STATE(LISTEN) <------------- STREAM <------------- PATH_ACK Figure 2: Multicast flow announcement and join 5.1. Flexicast Flow Announcement A Flexicast QUIC source announces a multicast flow using the FC_ANNOUNCE frame (see Section 11.1). The initial Connection ID derived during connection establishment between the source and the receiver cannot be reused on the multicast flow since it is unique for each receiver. On a multicast flow, Flexicast QUIC replaces the concept of Connection ID with the Flexicast Flow ID. Similarly to the Connection ID from [MULTIPATH-QUIC], the Flexicast Flow ID uniquely identifies a multicast flow. The Flexicast Flow ID MUST NOT be empty, as of [MULTIPATH-QUIC] specification. Using a Flexicast Flow ID, a multicast flow can change the addressing at lower protocol layers (UDP, IP) without causing packets to be delivered to the wrong endpoint. In [QUIC-TRANSPORT] and [MULTIPATH-QUIC], endhosts chose their source Connection IDs and advertise them to their peers using NEW_CONNECTION_ID frames. In Flexicast QUIC, the source decides the Flexicast Flow ID identifying a multicast flow and sends this value to receivers. Through the FC_ANNOUNCE frame, the source advertises the Flexicast Flow ID of the multicast flow to listen to. The advertised Flexicast Flow ID serves as the Destination Connection ID for packets sent on the multicast flow. _TBD: how to avoid colission. The FC_ANNOUNCE frame also contains the source address, destination address and UDP destination port number of the multicast flow. If the destination address is an IP multicast address, then the Navarre & Bonaventure Expires 1 September 2026 [Page 10] Internet-Draft FC-QUIC February 2026 multicast flow uses an IP multicast tree and the receiver MUST join this tree and listen to the specified UDP port number. If the destination address is the unicast IP address of the receiver, then the receiver MUST listen to the specified UDP port number on this address. _TBD: how to avoid colission with an already bound UDP destination port. The source MAY advertise multiple distinct multicast flows to a given receiver, i.e., multicast flows with distinct Flexicast Flow ID. The source MAY advertise updated information about a specific multicast flow by sending new FC_ANNOUNCE frames with increased sequence numbers. Upon reception of a new FC_ANNOUNCE frame updating information of an existing multicast flow with a smaller sequence number compared to the last received FC_ANNOUNCE frame, a receiver MUST silently discard the new FC_ANNOUNCE frame. The source MAY withdraw a multicast flow by sending a new FC_ANNOUNCE frame, with an increased sequence number, with null source and destination IP addresses. Upon reception of such frame, receivers MUST stop listening to packets received from the multicast flow. 5.2. Joining a Flexicast Flow Figure 3 illustrates the finite-state machine of a receiver from the start of the QUIC connection (Unaware) until it is ready to listen to packets on the multicast flow. After receiving an FC_ANNOUNCE frame advertising a multicast flow, a receiver MAY decide to join it. For example, the source can advertise multiple flows disseminating the same video stream in different qualities, letting the receiver choose the appropriate quality. Due to the scalability benefits from the point of view of the source and the network, it is encouraged that receivers do join the multicast flow. Multicast flow management is handled with the FC_STATE frame (see Section 11.2). The receiver sends an FC_STATE frame with the Flexicast Flow ID of the multicast flow it wants to join and the JOIN action. Navarre & Bonaventure Expires 1 September 2026 [Page 11] Internet-Draft FC-QUIC February 2026 .-----------------. | Unaware |<-----------------------------. .-----------------. | | | | Receives FC_ANNOUNCE frame | v | .-----------------. | | Aware, unjoined |<---------------------------. | .-----------------. | | | | | | Sends FC_STATE frame | | | with JOIN action | | v | | .-----------------. | | |Joined, needs key| | | .-----------------. | | | | | | Receives FC_KEY frame | | | with master secret | | v Receives/sends | | .-----------------. FC_STATE frame | | | Joined | with LEAVE action | | .-----------------. | | | | | | Sends FC_STATE frame | | | with LISTEN action | | v | | .-----------------. | | | Ready to listen |----------------------------. | .-----------------. | | Receives a withdraw FC_ANNOUNCE | .----------------------------------------. Figure 3: Receiver-side finite-state machine for a given multicast flow ID Navarre & Bonaventure Expires 1 September 2026 [Page 12] Internet-Draft FC-QUIC February 2026 Upon reception of an FC_STATE frame with the JOIN action, the source sends an FC_KEY frame, containing the TLS master secret that will be used to derive the set of keys necessary for the receiver to decrypt packets received on the multicast flow. The frame contains an indication on the current packet number sequence such that the receiver can correctly reconstitute the full packet number when receiving a QUIC packet on the flexicast flow The receiver SHOULD NOT process packets with a lower packet number, and applications SHOULD transmit through the unicast path any application data required for the receiver to correctly process subsequent packets received on the multicast flow ID. Starting from the advertised first packet number of interest, the source MUST retransmit on any path any lost reliable frames. Once the receiver received the FC_KEY frame and its underlying multicast network is ready to receive packets on the multicast flow, it sends an FC_STATE frame to the source with the LISTEN action. The Flexicast QUIC source SHOULD NOT consider the receiver as an active member of the multicast flow before it has received an FC_STATE with the LISTEN action from the receiver. This process avoids the unlikely case where the receiver wants to join the multicast flow, but no underlying multicast distribution tree could be constructed toward the receiver (e.g., it lies in a unicast-only network). By not considering such receiver as an active member of the group, the Flexicast QUIC source avoids considering all sent packets as lost, potentially impacting its congestion state. 5.3. Underlying (multicast) network If the IP destination address in the FC_ANNOUNCE frame is a multicast IP address, the receiver MUST notify the underlying network of its interest to receive multicast packets to this address. In an IP multicast network, this is done by sending an IGMP/MLD join on (S,G) in the case of single-source multicast. If the IP destination address in the FC_ANNOUNCE frame is the unicast address of the receiver, it means that the source uses unicast-duplication. The receiver MAY also wait to receive the FC_KEY frame of the corresponding multicast flow to avoid receiving packets that it will not be able to process before receiving the required TLS keys. 6. Multicast flow membership management Thanks to the FC_STATE frame, a Flexicast QUIC source knows the set of receivers listening to a specific multicast flow. Receivers MAY decide, at any point in time during the communication, to leave the multicast flow. Navarre & Bonaventure Expires 1 September 2026 [Page 13] Internet-Draft FC-QUIC February 2026 6.1. Receiver-side management Receivers leave a multicast flow by sending an FC_STATE frame with the LEAVE action. Upon reception of this frame, the Flexicast QUIC source MUST remove the receiver from the members of the multicast flow, and it MAY continue transmitting data through the unicast path with the receiver; the source MAY also decide to close the connection with the receiver, depending on the application. The receiver MUST drop any path state for the multicast flow regarding this multicast flow. The finite-state machine on the receiver-side MUST be reset to the same state as when it received the FC_ANNOUNCE for the first time. A receiver that previously left a multicast flow MAY attempt to join again the same flow, or another flow by restarting the phases from Section 5.2. 6.2. Source-side management At any point in time, the Flexicast QUIC source MAY decide to unilaterally remove a receiver from a multicast flow, by sending an FC_STATE frame with the LEAVE action. There are two reasons to decide on the source-side to remove receivers from the multicast flow: - A receiver is a bottleneck on the multicast flow, i.e., the bit-rate of the multicast flow becomes too low because of this receiver. In that case, the bottleneck receiver is removed from the specific multicast flow. The source can continue distributing the content either through the unicast path with this receiver, or by letting the receiver join another multicast flow. - A receiver experiences too many losses. Receivers send feedback to the source. Too many losses degrade the quality of experience for the application. To recover from such losses, there is a need for retransmissions, which can take up to several RTTs. The source SHOULD decide to remove the receiver from the multicast flow and continue receiving data through unicast, even temporarilly. A reason why it would be better to continue through the unicast path is that the underlying IP multicast tree may be failing. 7. Reliability The reliability mechanism of Flexicast QUIC uses the standard QUIC mechanisms. This section only details the reliability mechanisms for frames sent on the multicast flow. This document does not modify the reliability mechanism defined in [RFC9002] for packets sent on the unicast path. Navarre & Bonaventure Expires 1 September 2026 [Page 14] Internet-Draft FC-QUIC February 2026 Receivers regularly send PATH_ACK frames back to the source on their unicast path. Receivers MUST send PATH_ACK frames for packets received on the multicast flow on their unicast path with the source. A Flexicast QUIC source receiving an PATH_ACK from a receiver on the multicast flow MUST close the connection with this receiver with an error of type FC_PROTOCOL_VIOLATION. The PATH_ACK frames sent by the receivers on their unicast path include the path_id field to refer to the multicast flow. A major change between [RFC9002], and to some extent [MULTIPATH-QUIC] is that a Flexicast QUIC source receives acknowledgments from multiple receivers for the same data. A Flexicast QUIC source must wait for the acknowledgment from all receivers listening to the multicast flow before releasing state for the transmitted data. An acknowledgment-aggregation mechanism MUST be implemented, at least on the Flexicast QUIC source, to advance its state when all members of the multicast flow sent PATH_ACK frames to acknowledge data sent on the multicast flow. Bottleneck or malicious receivers may slow down, and even block the transmission of data, thus impacting the quality of service for other receivers. Similarly to [RFC9002], a Flexicast QUIC source may decide to stop the communication with a specific receiver if it does not regularly receive PATH_ACK frames from this receiver. A Flexicast QUIC source SHOULD remove bottleneck-inducing or malicious receivers from the multicast flow in that case, and MAY continue transmitting data through the unicast path with these receivers instead, thus relying on [RFC9002]. The Flexicast QUIC source is responsible to decide whether to send retransmitted frames on the multicast flow to all receivers, or specifically to receivers individually on their unicast path. Receivers are not impacted by this choice since the [MULTIPATH-QUIC] specification allows to retransmit frames on another path than the initial path on which they were sent. The first case would be more efficient if multiple receivers lost the same packet; the second case is more interesting for isolated losses to avoid healthy receivers receiving duplicate frames. 8. Congestion Control There are currently several possibilities regarding congestion control for Flexicast QUIC. A first idea is to maintain constant bit-rate delivery and exposing multiple multicast flows operating at different bit-rates. As such, if a receiver sees degradation in its communication (e.g., congestion or increased delay in the network), it may switch to a lower bit-rate multicast flow. However, this idea does not solve the problem of increasing the congestion in the Navarre & Bonaventure Expires 1 September 2026 [Page 15] Internet-Draft FC-QUIC February 2026 network. The other idea outlines the possibility to take into account all receiver-specific bit-rate to chose the overall bit-rate on the multicast flow, e.g., by requiring that the multicast flow bit-rate is the lowest bit-rate among all receivers listening to this multicast flow. Since receivers regularly send PATH_ACK frames, it is possible for the source to adjust a per-receiver bit-rate (or congestion window) and use the minimum value as the value for the multicast flow. Of course, such method paves the way to malicious receivers decreasing on-purpose the multicast flow bit-rate. Applications SHOULD provide to a Flexicast QUIC source a "minimum bit-rate" to ensure a minimum quality of service for the receivers. Malicious or bottleneck receivers with a per-receiver bit-rate below this minimum bit-rate SHOULD be removed from the multicast flow membership. Since the Flexicast QUIC source can unilaterally evict such receivers, it can adjust the multicast flow bit-rate without considering these receivers. A mix of both approaches is also possible. A Flexicast QUIC source may expose multiple multicast flow, each operating at different bit- rate windows. For example, a first window would operate at a minimum bit-rate of 2 Mbps and a maximum bit-rate of 5 Mbps; another multicast flow would operate between 5 Mbps and 10 Mbps,... Receivers falling below the 2 Mbps bit-rate SHOULD be evicted from flexicast delivery; a Flexicast QUIC source MAY decide to continue the delivery through the unicast path. 9. Flow Control Similarly to the congestion control, an aggregated flow control mechanism extends the standard QUIC flow control mechanism from [QUIC-TRANSPORT]. The multicast flow MUST respect the flow control limits of active members. Receivers actively listening to the multicast flow MUST send MAX_DATA and MAX_STREAM_DATA on their unicast path, similarly to [QUIC-TRANSPORT]. The multicast flow aggregates all flow control limits from active members and MUST set its limits to the minimum among all limits from the receivers. To ensure that the flow control does not violates any limit, the flow control MAY use values from different active receivers to update its flow control limits. For example with three receivers R0, R1, and R2, the multicast flow may update its max data using the value advertised by R0, its max stream data for stream id X using the value advertised by R1, and its max stream data for stream id Y using the value advertised by R2. Navarre & Bonaventure Expires 1 September 2026 [Page 16] Internet-Draft FC-QUIC February 2026 The source MAY remove bottleneck receivers from the set of active members if such receivers fail to update their flow control to ensure a minimum quality of service. In that case, the source MAY continue transmiting data to these receivers on their unicast path, again as a fall-back on unicast QUIC as defined in [QUIC-TRANSPORT]. Because the flow control limits are shared between multiple paths within the same connection, a receiver which previously fall backed on unicast delivery MAY rejoin a multicast flow if its flow control limits have been updated. 10. Packet protection Packet protection for QUIC version 1 is specified in Section 5 of [QUIC-TLS]. Section 4 of [MULTIPATH-QUIC] further expands this design when multiple paths with different packet number spaces are used. Because the multicast flow is shared among multiple receivers, this document modifies the design from Section 4 of [MULTIPATH-QUIC]. 10.1. Protection Keys This document extends the design from [MULTIPATH-QUIC] by requiring that all multicast flows use different TLS protection keys. Of course, these protections keys MUST be different from the protection keys derived during the handshake between the source and any receiver. For each multicast flow, the Flexicast QUIC source derives new random TLS keys that will be used to encrypt and decrypt the packets. The Flexicast QUIC source MUST derive these keys randomly, simulating a QUIC connection establishment alone. The master secret and used algorithm is sent through the FC_KEY frame (Section 11.3) on the unicast path to receivers joining a multicast flow. The master secret and algorithm are used to derive the TLS decryption keys on the receivers. Since no explicit path probing phase is used in Flexicast QUIC, the receiver can use the dedicated protection key context whenever receiving a packet from the multicast flow directly after receiving the FC_KEY frame from the source. Navarre & Bonaventure Expires 1 September 2026 [Page 17] Internet-Draft FC-QUIC February 2026 10.2. Nonce Calculation Section 4 of [MULTIPATH-QUIC] expands the computation of the Nonce from Section 5.3 of [QUIC-TLS] to integrate the least significant 32 bits of the Path ID to guarantee its uniqueness. A multicast flow is shared among multiple receivers simultaneously, thus requiring that all receivers share the same Path ID for the same multicast flow. Since receivers are allowed to dynamically change the multicast flows they listen, it is impossible to ensure that all receivers use the same Path ID for the same multicast flow. However, since each multicast flow uses its own set of TLS keys, the computation of the Nonce is decorelated between any pair of multicast flows, and between any multicast flow and any unicast path with a receiver. It is therefore not mandatory anymore to use the Path ID to ensure the uniqueness of the Nonce. As such, this document removes the Path ID from the computation of the Nounce when sending packets on the multicast flows. 10.3. Key Update TODO in a future version of the draft. 11. New Frames All frames defined in this document MUST only be sent in 1-RTT packets. If an endpoint receives a flexicast-specific frame in a different packet type, it MUST close the connection with an error of type FRAME_ENCODING_ERROR. Receipt of flexicast-specific frames related to a Flexicast Flow ID that is not unknown by endpoint MUST be treated as a connection error of type FC_PROTOCOL_VIOLATION. If an endpoint receives a flexicast-specific frame with a Flexicast Flow ID that it cannot process anymore (e.g., the multicast flow might have been abandoned), it MUST silently ignore the frame. The new frames introduced below are for control-specific purpose only, and MUST NOT be sent on the Multicast flow. Receipt of any of the following frames on the Multicast flow MUST be trated as a connection error of type FC_PROTOCOL_VIOLATION. Navarre & Bonaventure Expires 1 September 2026 [Page 18] Internet-Draft FC-QUIC February 2026 11.1. FC_ANNOUNCE frame The FC_ANNOUNCE frame informs the receiver that a Multicast flow is available or has been updated. FC_ANNOUNCE frames MUST NOT be sent by the receiver. A Flexicast QUIC source receiving an FC_ANNOUNCE frame MUST close the connection with a connection error of type FC_PROTOCOL_VIOLATION. FC_ANNOUNCE frames are formatted as shown in Figure 4. FC_ANNOUNCE Frame { Type (i) = TBD-00, Length (8), Flexicast Flow ID (8..160), Sequence number (i), IP Version (8), Source IP (32, 128), Group IP (32, 128), UDP Port (16), Ack delay timer (64), } Figure 4: FC_ANNOUNCE Frame Format FC_ANNOUNCE frames contain the following fields: Length: An 8-bit unsigned integer containing the length of the Flexicast Flow ID. Values less than 1 and greater than 20 are invalid and MUST be treated as a connection error of type FRAME_ENCODING_ERROR. Flexicast Flow ID: A Flexicast Flow ID of the specified length. Sequence number: A variable-length integer indicating the sequence of the frame. The number is monotonically increasing within a QUIC connection and is chosen by the sender. It helps the receiver to order FC_ANNOUNCE frames by recency. A receiver SHOULD ignore frames with a Sequence Number lower or equal to the highest Sequence Number received. IP Version: An 8-bit unsigned integer containing the version of IP used to advertise the Source IP and Group IP. Values different than 4 (for IPv4) and 6 (IPv6) are invalid and MUST be treated as a connection error of type FRAME_ENCODING_ERROR. Source IP: The IP address of the multicast source, used for Single- Source Multicast. Navarre & Bonaventure Expires 1 September 2026 [Page 19] Internet-Draft FC-QUIC February 2026 Group IP: Either an IP multicast address or the address of the receiver. UDP Port: The UDP destination port. Ack delay timer: A 64-bit unsigned integer containing the delay, in ms, between two acknowledgments from a receiver. FC_ANNOUNCE frames are ack-eliciting. If a packet containing an FC_ANNOUNCE frame is considered lost, the peer SHOULD repeat it. Sources are allowed to send multiple times FC_ANNOUNCE frames with an increasing sequence number for the same Flexicast Flow ID. New FC_ANNOUNCE frames MAY contain updated information, e.g., a new Ack delay timer. Sources are allowed to advertise multiple Multicast flows by sending multiple parallel FC_ANNOUNCE frames with distinct Flexicast Flow IDs. The Sequence number is linked to a specific Flexicast Flow ID. The same Sequence number can be used for two distinct Flexicast Flow IDs. A Flexicast QUIC can withdraw a multicast flow by sending an FC_ANNOUNCE frame with null Source IP and Group IPs and identifying the multicast flow using the Flexicast Flow ID. Upon reception of a new FC_ANNOUNCE frame updating information of an existing multicast flow with an increased sequence number compared to the last received FC_ANNOUNCE frame, a receiver MUST update multicast flow information. 11.2. FC_STATE frame The FC_STATE frame informs the endpoint of the state of the Flexicast receiver in the Multicast flow. FC_STATE frames MAY be sent by both endpoints (i.e., receiver and source). FC_STATE frames are formatted as shown in Figure 5. FC_STATE frame { Type (i) = TDB-01, Length (8), Flexicast Flow ID (8..160), Sequence number (i), Action (u64), } Figure 5: FC_STATE Frame Format FC_STATE frames contain the following fields: Navarre & Bonaventure Expires 1 September 2026 [Page 20] Internet-Draft FC-QUIC February 2026 Length: An 8-bit unsigned integer containing the length of the Flexicast Flow ID. Values less than 1 and greater than 20 are invalid and MUST be treated as a connection error of type FRAME_ENCODING_ERROR. Flexicast Flow ID: The Flexicast Flow ID of the Multicast flow that this frame relates to. Sequence number: The monotically increasing sequence number related to the advertised Flexicast Flow ID. Action: The bit-encoded action, defined in Section Section 11.2.1. FC_STATE frames are ack-eliciting. If a packet containing an FC_STATE frame is considered lost, the peer SHOULD repeat it. For a given Multicast flow (i.e., identical Flexicast Flow ID), both endpoints use their own Sequence number. A receiver sending an FC_STATE frame informs the source of its status regarding the Multicast flow indicated by the Flexicast Flow ID. The source MAY also send FC_STATE frames to a receiver to unilaterally change the status of the receiver within the Multicast flow indicated by the Flexicast Flow ID. 11.2.1. FC_STATE actions This section lists the defined Actions encoded in an FC_STATE frame. An endpoint receiving an unknown value MUST treat it as a connection error of type FC_PROTOCOL_VIOLATION. JOIN (0x01): The receiver joins the Multicast flow. LEAVE (0x02): The receiver leaves the Multicast flow. READY (0x03): The receiver is ready to receive content on the Multicast flow. The JOIN and READY actions are receiver-specific. These actions MUST NOT be sent inside an FC_STATE frame sent by the source. A receiver receiving an FC_STATE frame with any of the following actions MUST treat it as a connection error of type FC_PROTOCOL_VIOLATION. The action LEAVE MAY be sent by both the receiver and the source, as detailed in Section 6. Navarre & Bonaventure Expires 1 September 2026 [Page 21] Internet-Draft FC-QUIC February 2026 11.3. FC_KEY frame The FC_KEY frame informs a receiver of the security keys used on a Multicast flow joined by the receiver. FC_KEY frames MUST NOT be sent by the receiver. A Flexicast QUIC source receiving an FC_KEY frame MUST close the connection with a connection error of type FC_PROTOCOL_VIOLATION. FC_KEY frames are formatted as shown in Figure 6. FC_KEY Frame { Type (i) = TDB-02, Length(8), Flexicast Flow ID(8..160), Sequence number (i), Packet number (i), Key length (i), Key (..), Algorithm (64), } Figure 6: FC_KEY Frame Format FC_KEY frames contain the following fields: Length: An 8-bit unsigned integer containing the length of the Flexicast Flow ID. Values less than 1 and greater than 20 are invalid and MUST be treated as a connection error of type FRAME_ENCODING_ERROR. Flexicast Flow ID: The Flexicast Flow ID of the Multicast flow that this frame relates to. Sequence number: The monotically increasing sequence number related to the advertised Flexicast Flow ID. Packet number: The first packet number that the receiver must receive with this key, Key length: A var-int indicating the length of the security key. Key: Byte-sequence of the decryption key of the Multicast flow. Algorithm: The bit-encoded algorithm used for decryption, defined in Section Section 11.3.1. FC_KEY frames are ack-eliciting. If a packet containing an FC_STATE frame is considered lost, the peer SHOULD repeat it. Navarre & Bonaventure Expires 1 September 2026 [Page 22] Internet-Draft FC-QUIC February 2026 The source MAY send new FC_KEY frames with an increased sequence number to notify a new decryption key. This mechanism can be used to provide backward and forward secrecy with dynamic Flexicast groups. 11.3.1. FC_KEY algorithms The algorithms and their encoding follow [RFC8446] and {QUIC-TLS}. TODO: expand this section. 12. Discussion This document has defined a simple extension to Multipath QUIC that enables a QUIC connection to simulatenously use unicast paths and multicast trees to deliver the same data to a set of receivers. The proposed protocol can be extended in different ways and improvements will be proposed in separate documents. We briefly describe some of these possible extensions. This version of Flexicast QUIC uses the existing QUIC mechanisms to retransmit lost frames. It is well known that Forward Erasure Correction can improve the performance of multicast transmission when losses occur. Several authors have proposed techniques to add Forward Erasure Correction to QUIC [QUIRL], [rQUIC], [I-D.draft-michel-quic-fec]. FEC can be sent a priori to enable receivers to recover from different packet losses without having to wait for retransmissions or a posteriori by sending a repair symbol that enables different receivers to recover different lost frames. This version of Flexicast QUIC uses a key shared between the source and all receivers to authenticate and encrypt the data sent by the source over the multicast tree. A malicious receiver who has received the shared key could inject fake data over the multicast tree provided that it can spoof the IP address of the source. Techniques have been proposed to authenticate the frames sent by the source [I-D.draft-krose-multicast-security]. Subsequent documents will detail how Flexicast QUIC can be extended to support such techniques. Multipath QUIC assumes that the congestion control mechanism operates per path. For Flexicast QUIC, a different congestion control mechanism will be required for the unicast paths and the multicast tree. For the former, the QUIC congestion control mechanisms [RFC9002] are applicable. For the latter, multicast specific congestion control mechanisms such as [RFC4654] will be required. The current prototype uses a variant of the CUBIC congestion control. Navarre & Bonaventure Expires 1 September 2026 [Page 23] Internet-Draft FC-QUIC February 2026 13. Security Considerations This section highlights security considerations when operating a Flexicast QUIC communication between a single source and multiple receivers. Since a unique multicast flow is shared among multiple receivers, additional threats must be addresses compared to a one-to- one (Multipath) QUIC connection. The security considerations when falling-back on unicast are similar to Section 10 of [MULTIPATH-QUIC]. TODO: this section will be expanded in future versions of this document. 13.1. Sending the TLS key secrets in FC_KEY frames TODO: discuss here the potential issues by sending the TLS key secrets in the FC_KEY frames. I don't think there is any problem since the secrets are sent through a secure channel. 13.2. Malicious Receivers in a Flexicast Flow Malicious receivers may listen to a multicast flow in the presence of healthy receivers. This has several impacts that are addressed in this section. 13.2.1. Cycling Between Joins and Leaves A malicious receiver may issuing cycles of FC_STATE with JOINs and LEAVEs actions to the source, thus updating the state of the Flexicast QUIC source. Since a Flexicast QUIC source can decide to unilaterally remove receivers from a multicast flow, the source can decide to reject FC_STATE JOINs from a malicious receiver. The source MAY send an FC_STATE frame withdrawing a multicast flow specifically for this receiver to avoid the receiver from perpetually sending FC_STATE JOINs frames. Additionally, applications SHOULD provide a mechanism to avoid such receivers to periodically join and leave the same multicast flow to saturate the Flexicast QUIC source. The connection with such malicious receiver will fall-back on unicast delivery, thus relying on [QUIC-TRANSPORT] to deal with it. 13.2.2. Intentionally Decreasing the Flexicast Flow Performance Section 6.2 mentions two reasons that could include malicious receivers wishing to degrade the overall perfomance of communication through the multicast flow. By letting the source unilaterally decide to remove receivers from a multicast flow, the impact of malicious receivers is limited. Navarre & Bonaventure Expires 1 September 2026 [Page 24] Internet-Draft FC-QUIC February 2026 14. IANA Considerations IANA is requested to assign three new QUIC frame types from the "QUIC Frame Types" registry available at https://www.iana.org/assignments/quic/quic.xhtml#quic-frame-types * TBD-00 for the FC_ANNOUNCE frame defined in Section 11.1 * TBD-01 for the FC_STATE frame defined in Section 11.2 * TBD-02 for the FC_KEY frame defined in Section 11.3 IANA is requested to assign a new QUIC transport parameter from the "QUIC Transport Parameters" registry available at https://www.iana.org/assignments/quic/quic.xhtml#quic-transport * TBD-03 for the flexicast_support transport parameter defined in Section 4 15. References 15.1. Normative References [MULTIPATH-QUIC] Liu, Y., Ma, Y., De Coninck, Q., Bonaventure, O., Huitema, C., and M. Kühlewind, "Managing multiple paths for a QUIC connection", Work in Progress, Internet-Draft, draft-ietf- quic-multipath-20, 20 February 2026, . [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, . [QUIC-TRANSPORT] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Navarre & Bonaventure Expires 1 September 2026 [Page 25] Internet-Draft FC-QUIC February 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 15.2. Informative References [DIOT] Diot, C., Levine, B., Lyles, B., Kassem, H., and D. Balensiefen, "Deployment issues for the IP multicast service and architecture", Institute of Electrical and Electronics Engineers (IEEE), IEEE Network vol. 14, no. 1, pp. 78-88, DOI 10.1109/65.819174, 2000, . [FCQUIC] Navarre, L., "AAA", ACM SIGCOMM Computer Communication Review (CCR), March 2025, . [I-D.draft-krose-multicast-security] Rose, K., Franke, M., and J. Holland, "Security and Privacy Considerations for Multicast Transports", Work in Progress, Internet-Draft, draft-krose-multicast-security- 07, 7 May 2025, . [I-D.draft-michel-quic-fec] Michel, F. and O. Bonaventure, "Forward Erasure Correction for QUIC loss recovery", Work in Progress, Internet-Draft, draft-michel-quic-fec-01, 23 October 2023, . [I-D.jholland-quic-multicast-08] Holland, J., Pardue, L., Franke, M., and K. Rose, "Multicast Extension for QUIC", Work in Progress, Internet-Draft, draft-jholland-quic-multicast-08, 2 January 2026, . Navarre & Bonaventure Expires 1 September 2026 [Page 26] Internet-Draft FC-QUIC February 2026 [I-D.pardue-quic-http-mcast] Pardue, L., Bradbury, R., and S. Hurst, "Hypertext Transfer Protocol (HTTP) over multicast QUIC", Work in Progress, Internet-Draft, draft-pardue-quic-http-mcast-11, 4 July 2022, . [QUIRL] Michel, F. and O. Bonaventure, "QUIRL: Flexible QUIC Loss Recovery for Low Latency Applications", Institute of Electrical and Electronics Engineers (IEEE), IEEE/ACM Transactions on Networking vol. 32, no. 6, pp. 5204-5215, DOI 10.1109/tnet.2024.3453759, December 2024, . [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, . [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, . [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification", RFC 4654, DOI 10.17487/RFC4654, August 2006, . [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May 2021, . [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, . [rQUIC] Garrido, P., Sanchez, I., Ferlin, S., Aguero, R., and O. Alay, "rQUIC: Integrating FEC with QUIC for Robust Wireless Communications", IEEE, 2019 IEEE Global Communications Conference (GLOBECOM), DOI 10.1109/globecom38437.2019.9013401, December 2019, . Navarre & Bonaventure Expires 1 September 2026 [Page 27] Internet-Draft FC-QUIC February 2026 Appendix A. Existing implementation and initial results. The design of Flexicast QUIC is presented in a scientific paper, accepted at ACM SIGCOMM Computer Communication Review (CCR) [FCQUIC]. We provide a proof of concept implementation of Flexicast QUIC, relying on Cloudflare quiche and the multipath extension. The source code of Flexicast QUIC is freely available for experimentations at https://github.com/IPNetworkingLab/flexicast-quic. Acknowledgments Louis Navarre was partially funded as an F.R.S-FNRS Research Fellow. This work has been partially supported by the Walloon Region as part of the funding of the FRFS-WEL-T strategic axis. We thank Maxime Piraux and Gorry Fairhurst for their valuable reviews. Authors' Addresses Louis Navarre UCLouvain Belgium Email: louis.navarre@uclouvain.be Olivier Bonaventure UCLouvain & WELRI Belgium Email: olivier.bonaventure@uclouvain.be Navarre & Bonaventure Expires 1 September 2026 [Page 28]