Skip to main content

Flexicast QUIC: combining unicast and multicast in a single QUIC connection
draft-navarre-quic-flexicast-00

Document Type Active Internet-Draft (individual)
Authors Louis Navarre , Olivier Bonaventure
Last updated 2024-10-21
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
On agenda quic at IETF-121
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-navarre-quic-flexicast-00
QUIC                                                          L. Navarre
Internet-Draft                                                 UCLouvain
Intended status: Experimental                             O. Bonaventure
Expires: 24 April 2025                                 UCLouvain & WELRI
                                                         21 October 2024

    Flexicast QUIC: combining unicast and multicast in a single QUIC
                               connection
                    draft-navarre-quic-flexicast-00

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 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 24 April 2025                 [Page 1]
Internet-Draft                   FC-QUIC                    October 2024

   This Internet-Draft will expire on 24 April 2025.

Copyright Notice

   Copyright (c) 2024 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. . . . . . . . . . . . . . .   7
   4.  Handshake Negotiation and Transport parameter . . . . . . . .   8
   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  . . . . . . . . . . . . .  12
   6.  Flexicast flow membership management  . . . . . . . . . . . .  12
     6.1.  Receiver-side management  . . . . . . . . . . . . . . . .  13
     6.2.  Source-side management  . . . . . . . . . . . . . . . . .  13
   7.  Reliability . . . . . . . . . . . . . . . . . . . . . . . . .  13
   8.  Congestion Control  . . . . . . . . . . . . . . . . . . . . .  14
   9.  Flow Control  . . . . . . . . . . . . . . . . . . . . . . . .  15
   10. Packet protection . . . . . . . . . . . . . . . . . . . . . .  15
     10.1.  Protection Keys  . . . . . . . . . . . . . . . . . . . .  15
     10.2.  Nonce Calculation  . . . . . . . . . . . . . . . . . . .  16
     10.3.  Key Update . . . . . . . . . . . . . . . . . . . . . . .  16
   11. New Frames  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     11.1.  FC_ANNOUNCE frame  . . . . . . . . . . . . . . . . . . .  17
     11.2.  FC_STATE frame . . . . . . . . . . . . . . . . . . . . .  18
       11.2.1.  FC_STATE actions . . . . . . . . . . . . . . . . . .  19
     11.3.  FC_KEY frame . . . . . . . . . . . . . . . . . . . . . .  20
       11.3.1.  FC_KEY algorithms  . . . . . . . . . . . . . . . . .  21
   12. Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .  21
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  22
     13.1.  Malicious Receivers in a Flexicast Flow  . . . . . . . .  22
       13.1.1.  Cycling Between Joins and Leaves . . . . . . . . . .  22

Navarre & Bonaventure     Expires 24 April 2025                 [Page 2]
Internet-Draft                   FC-QUIC                    October 2024

       13.1.2.  Intentionally Decreasing the Flexicast Flow
               Performance . . . . . . . . . . . . . . . . . . . . .  23
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  23
     15.2.  Informative References . . . . . . . . . . . . . . . . .  24
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  25
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26

1.  Introduction

   Starting from the initially 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 is
   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, the applications must implement a multicast solution
   and a unicast solution.  This increases the complexity and the cost
   of the application.  For this reason, many applications that send the
   same information to a large set of receivers, such as streaming
   services and 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.

   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.
   Multicast extensions to QUIC have already been proposed in
   [I-D.pardue-quic-http-mcast] and [I-D.jholland-quic-multicast-05].
   To our knowledge, these extensions have not been fully implemented
   and deployed.

Navarre & Bonaventure     Expires 24 April 2025                 [Page 3]
Internet-Draft                   FC-QUIC                    October 2024

   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.
   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

Navarre & Bonaventure     Expires 24 April 2025                 [Page 4]
Internet-Draft                   FC-QUIC                    October 2024

   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 over both
   paths.  When a QUIC packet needs to be send, the packet scheduler
   selects the relevant path.  If a QUIC frame is lost over one path, it
   can be retransmitted over the other paths.

   Flexicast QUIC extends Multipath QUIC by requiring that each path
   uses 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 with multicast support receive the same packet.

   The case were the IP destination address is _not_ an IP multicast
   address is discussed later in this document.  In short: use packet
   replication at the source, e.g., using sendmmsg, using the unicast
   destination address of the receivers.  Scales at the source because
   we generate and encrypt only one packet, and duplicating the bytes is
   straightforward.

   A Flexicast QUIC connection starts with a handshake like a regular
   QUIC connection.  R1, R2 and R3 establish a connection to 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.  They remain open during the whole communication 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 flexicast flow.  A *flexicast flow* is a
   unidirectional multipath path from a source to a group of receivers.
   An important characteristic of a flexicast 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
   flexicast flow.

   Flexicast QUIC supports two types of flexicast flows.  The first type
   flexicast flow is an IP multicast tree, as illustrated in Figure 1.
   The source relies on an underlying IP multicast network to create an

Navarre & Bonaventure     Expires 24 April 2025                 [Page 5]
Internet-Draft                   FC-QUIC                    October 2024

   IP multicast tree and selects a set of encryption and authentication
   keys.  It then advertises flexicast flow using the FC_ANNOUNCE frame
   to the receivers.  The FC_ANNOUNCE frame contains information such as
   the Flexicast Flow ID, i.e., the equivalent of the Connection ID for
   the flexicast flow, and the source and multicast group IP addresses
   that the receivers use to join the underlying IP multicast tree.  The
   source then uses the FC_KEY frame to avertise the shared keys to each
   receiver.  They can now receive and decrypt the data sent by the
   source along the multicast tree.  The Flexicast QUIC source uses this
   flexicast flow to efficiently sends 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 flexicast flow or
   over a specific unicast path, e.g. when some data was missing at only
   one receiver.

   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 flexicast 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 flexicast flow where
   it replicates each packet towards each receiver.  It also sends an
   FC_ANNOUNCE frame to advertise the flexicast flow, using the
   receiver's IP address as a destination instead of a multicast address
   and later an FC_KEY frame containing the shared keys.

   +----------------------------------------+
   |   +----------------------------+       |    =======> flexicast flow
   |   |                            |       |
   |   |                            |       |    <------> unicast path
   |   v      239.239.23.35:4433    v       |
   +-> S ==============+==========> R1      |
       ^               \\                   v
       |                +=================> R2
       |
       +----------------------------> R3

Navarre & Bonaventure     Expires 24 April 2025                 [Page 6]
Internet-Draft                   FC-QUIC                    October 2024

     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 flexicast flow from the source
       to a set of receivers relyinf on a multicast distribution tree

   At any point in time, if the network conditions of a receiver of a
   flexicast flow degrade, e.g., because the underlying multicast tree
   fails or because the receiver moves into a non-multicast network, it
   can leave the flexicast flow and continue receiving content through
   its unicast path.  The seamless transition between a flexicast flow
   and a unicast path is possible because these are Multipath QUIC
   paths.

   Flexicast QUIC offers full reliability by retransmitting lost frames
   either to all receivers on the flexicast flow, or per-receiver using
   their unicast path.

3.1.  Extensions to Multipath QUIC.

   Flexicast QUIC modifies Multipath QUIC in three ways to enable the
   utilization of a shared unidirectional path, the flexicast flow, as
   one of the Multipath QUIC paths.  The flexicast 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 <source address,
       group address>.

   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 flexicast
   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
   flexicast 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 flexicast flow at the IP
   multicast address provided by the source.

Navarre & Bonaventure     Expires 24 April 2025                 [Page 7]
Internet-Draft                   FC-QUIC                    October 2024

   Furthermore, the data received over the flexicast flow cannot be
   acknowledged over this path since it is unidirectional.  Because
   Flexicast QUIC uses Multipath QUIC, ACK frames are replaced by MP_ACK
   frames.  Flexicast QUIC receivers MUST send acknowledgments to the
   source using MP_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 flexicast
   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 flexicast flow must
   be encrypted and authenticated.  However, these packets cannot be
   encrypted using the TLS keys derived during the QUIC connection
   establishment since each unicast path has its own set of TLS keys.
   To secure the transmission of Flexicast QUIC packets along the
   flexicast flow, the 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.

   Section 10 gives more details on the modifications to
   [MULTIPATH-QUIC] to protect packets sent on the flexicast 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 TBD-03): the presence of
      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.

Navarre & Bonaventure     Expires 24 April 2025                 [Page 8]
Internet-Draft                   FC-QUIC                    October 2024

   The support of the flexicast extension is conditioned to the support
   of the multipath extension, as defined in [MULTIPATH-QUIC].  Since a
   Flexicast flow is a new multipath path, the support of multipath,
   with sufficient (e.g., at least 2) path ID, is required, as defined
   in Section 2 of [MULTIPATH-QUIC].

   An endpoint receiving the flexicast_support transport parameter from
   its peer, without support for multipath MUST ignore the
   flexicast_support transport parameter, as if the peer does not
   support the flexicast extension.

   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 flexicast
   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 flexicast
   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 flexicast flow, e.g. an IP
   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 flexicast flow.  The receiver returns an
   FC_STATE(LISTEN) frame to indicate that it receives frames over the
   flexicast flow.

   Source                                        Receiver

   QUIC handshake      <------------>      QUIC handshake

   FC_ANNOUNCE         ------------->
                       <-------------      FC_STATE(JOIN)
   FC_KEY              ------------->
                       <-------------    FC_STATE(LISTEN)

               Figure 2: Flexicast flow announcement and join

Navarre & Bonaventure     Expires 24 April 2025                 [Page 9]
Internet-Draft                   FC-QUIC                    October 2024

5.1.  Flexicast Flow Announcement

   A Flexicast QUIC source announces a flexicast flow using the
   FC_ANNOUNCE frame (see Section 11.1).  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 flexicast flow.  The Flexicast Flow ID MUST NOT
   be empty, as of [MULTIPATH-QUIC] specification.  Using a Flexicast
   Flow ID, a flexicast 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 their peers through
   NEW_CONNECTION_ID frames.  In Flexicast QUIC, the source decides the
   Flexicast Flow ID identifying a flexicast flow and forwards this
   value to receivers.

   Through the FC_ANNOUNCE frame, the source advertises the Flexicast
   FLow ID of the flexicast flow to listen to.  As the Flexicast Flow ID
   will serve as a "destination Connection ID" for the flexicast flow,
   receivers willing to join the flexicast flow MUST add this Flexicast
   Flow ID as a new "source Connection ID". _TODO: how to handle the
   case were the receiver already has this Flexicast Flow ID as a source
   Connection ID?_

   The FC_ANNOUNCE frame also contains the source address, destination
   address and UDP destination port number of the flexicast flow.  If
   the destination address is an IP multicast address, then the
   flexicast flow uses an IP multicast tree and the receiver MUST join
   this tree and listen to the UDP port number.  If the destination
   address is the unicast IP address of the receiver, then the receiver
   MUST list to the UDP port number on this address.  Since the IP
   destination address is a multicast address, this system is not
   impacted by NATs.

   The source MAY advertise multiple distinct flexicast flows to a given
   receiver, i.e., flexicast flows with distinct Flexicast Flow ID.  The
   source MAY advertise updated information about a specific flexicast
   flow by sending new FC_ANNOUNCE frames with increased sequence
   numbers.  Upon reception of a new FC_ANNOUNCE frame updating
   information of an existing flexicast flow with an increased sequence
   number compared to the last received FC_ANNOUNCE frame, a receiver
   MUST update flexicast flow information.  Upon reception of a new
   FC_ANNOUNCE frame updating information of an existing flexicast flow
   with a smaller sequence number compared to the last received
   FC_ANNOUNCE frame, a receiver MUST silently discard the new
   FC_ANNOUNCE frame.

Navarre & Bonaventure     Expires 24 April 2025                [Page 10]
Internet-Draft                   FC-QUIC                    October 2024

   The source MAY withdraw a flexicast 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 flexicast 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 flexicast flow.  After receiving an FC_ANNOUNCE frame
   advertising a flexicast flow, a receiver SHOULD decide to join it.
   Flexicast 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 flexicast flow it wants to join and the JOIN
   action.

   .-----------------.
   |     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 |
           .----------------------------------------.

Navarre & Bonaventure     Expires 24 April 2025                [Page 11]
Internet-Draft                   FC-QUIC                    October 2024

        Figure 3: Receiver-side finite-state machine to listen to a
                               flexicast flow

   Upon reception of the 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 flexicast flow.  The frame also contains the
   first packet number that the receiver MAY receive with this key.

   Once the receiver received the FC_KEY frame and its underlying
   multicast network is ready to receive packets on the flexicast 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 flexicast flow before it has received an
   FC_STATE with the LISTEN action from the receiver.

5.3.  Underlying (multicast) network

   In parallel of sending the FC_STATE frame with the JOIN action, the
   receiver MUST notify the underlying routing network its willingness
   to receive packets from the flexicast flow.  If the IP destination
   address received from the MC_ANNOUNCE is a multicast IP address, the
   receiver must notify the underlying network 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 received from the
   MC_ANNOUNCE is the unicast address of the receiver, it means that
   unicast-duplication mode is used to receive flexicast flow packets.
   The receiver MAY also wait to receive the FC_KEY frame of the
   corresponding flexicast flow to avoid receiving packets that it will
   not be able to process before receiving the required TLS keys.

6.  Flexicast flow membership management

   Thanks to the FC_STATE frame, a Flexicast QUIC source knows the set
   of receivers listening to a specific flexicast flow.  Receivers MAY
   decide, at any point in time during the communication, to leave the
   flexicast flow.  However, receivers SHOULD only leave a flexicast
   flow only if network conditions are not met to ensure a good quality
   of experience for the applications.  The exact metrics defining "good
   enough network conditions" is out of scope of this document.

Navarre & Bonaventure     Expires 24 April 2025                [Page 12]
Internet-Draft                   FC-QUIC                    October 2024

6.1.  Receiver-side management

   Receivers leave a flexicast flow by sending an FC_STATE frame with
   the LEAVE action.  Upon reception of this frame, the Flexicast QUIC
   source MUST NOT consider anymore the receiver as a member of the
   flexicast flow, and it MUST continue transmitting data through the
   unicast path with the receiver.  The receiver SHOULD drop any path
   state for the flexicast flow regarding this flexicast 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 flexicast 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 flexicast 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 flexicast flow: - A receiver is a bottleneck on
   the flexicast flow, i.e., the bit-rate of the flexicast flow becomes
   too low because of this receiver.  In that case, the bottleneck
   receiver is removed from the specific flexicast flow.  The source can
   continue distributing the content either through the unicast path
   with this receiver, or by letting the receiver join another flexicast
   flow. - A receiver experiences too many losses.  Receivers send
   feedback to the source.  Too many losses degrade the quality of
   experience for the applications.  To recover from them, there is a
   need for retransmissions, which can take up to several RTTs.  The
   source SHOULD decide to remove the receiver from the flexicast 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
   mechanism.  This section only details the reliability mechanism for
   frames sent on the flexicast flow.  This document does not modify the
   reliability mechanism defined in [RFC9002] for packets sent on the
   unicast path.

   Receivers regularly send MP_ACK frames back to the source on their
   unicast path.  Receivers MUST NOT send MP_ACK on the flexicast flow
   since this path is unidirectional.  A Flexicast QUIC source receiving

Navarre & Bonaventure     Expires 24 April 2025                [Page 13]
Internet-Draft                   FC-QUIC                    October 2024

   an MP_ACK from a receiver on the flexicast flow MUST close the
   connection with this receiver with an error of type
   FC_PROTOCOL_VIOLATION.  The MP_ACK frames sent by the receivers on
   their unicast path include the path_id field to refer to the
   flexicast 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
   flexicast 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 flexicast flow sent MP_ACK frames to acknowledge data sent on the
   flexicast 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 receive regularly MP_ACK frames from this receiver.  A Flexicast
   QUIC source SHOULD remove bottleneck-inducing or malicious receivers
   from the flexicast 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 flexicast flow to all receivers, or
   specifically to receivers individually on their unicast path.
   Receivers are not impacted by this choice since [MULTIPATH-QUIC]
   specification authorizes 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 flexicast flows operating at
   diffeent 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 flexicast flow.  However, this idea
   does not solve the problem of increasing the congestion in the
   network.

Navarre & Bonaventure     Expires 24 April 2025                [Page 14]
Internet-Draft                   FC-QUIC                    October 2024

   The other idea outlines the possibility to take into account all
   receiver-specific bit-rate to chose the overall bit-rate on the
   flexicast flow, e.g., by requiring that the flexicast flow bit-rate
   is the lowest bit-rate among all receivers listening to this
   flexicast flow.  Since receivers regularly send MP_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
   flexicast flow.  Of course, such method paves the way to malicious
   receivers decreasing on-purpose the flexicast 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 flexicast flow
   membership.  Since the Flexicast QUIC source can unilaterally evict
   such receivers, it can adjust the flexicast flow bit-rate without
   considering these receivers.

   A mix of both approaches is also possible.  A Flexicast QUIC source
   may expose multiple flexicast 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
   flexicast 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

   To be detailed in a future version of the document.

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 flexicast 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 flexicast 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.

Navarre & Bonaventure     Expires 24 April 2025                [Page 15]
Internet-Draft                   FC-QUIC                    October 2024

   For each flexicast 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 flexicast 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 flexicast flow directly after receiving
   the FC_KEY frame from the source.

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 flexicast flow is
   shared among multiple receivers simultaneously, thus requiring that
   all receivers share the same Path ID for the same flexicast flow.
   Since receivers are allowed to dynamically change the flexicast flows
   they listen, it is impossible to ensure that all receivers use the
   same Path ID for the same flexicast flow.

   However, since each flexicast flow uses its own set of TLS keys, the
   computation of the Nonce is decorelated between any pair of flexicast
   flows, and between any flexicast 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 flexicast 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.

Navarre & Bonaventure     Expires 24 April 2025                [Page 16]
Internet-Draft                   FC-QUIC                    October 2024

   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 flexicast 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 Flexicast flow.  Receipt of any of
   the following frames on the Flexicast flow MUST be trated as a
   connection error of type FC_PROTOCOL_VIOLATION.

11.1.  FC_ANNOUNCE frame

   The FC_ANNOUNCE frame informs the receiver that a Flexicast 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: The monotically increasing sequence number related
   to the advertised Flexicast Flow ID.

Navarre & Bonaventure     Expires 24 April 2025                [Page 17]
Internet-Draft                   FC-QUIC                    October 2024

   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.

   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 Flexicast 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 flexicast flow by sending an
   FC_ANNOUNCE frame with null Source IP and Group IPs and identifying
   the flexicast flow using the Flexicast Flow ID.

11.2.  FC_STATE frame

   The FC_STATE frame informs the endpoint of the state of the Flexicast
   receiver in the Flexicast 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.

Navarre & Bonaventure     Expires 24 April 2025                [Page 18]
Internet-Draft                   FC-QUIC                    October 2024

   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:

   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 Flexicast 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 Flexicast 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 Flexicast 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 Flexicast 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 Flexicast flow.

   LEAVE (0x02): The receiver leaves the Flexicast flow.

Navarre & Bonaventure     Expires 24 April 2025                [Page 19]
Internet-Draft                   FC-QUIC                    October 2024

   READY (0x03): The receiver is ready to receive content on the
   Flexicast 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.

11.3.  FC_KEY frame

   The FC_KEY frame informs a receiver of the security keys used on a
   Flexicast 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 Flexicast 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,

Navarre & Bonaventure     Expires 24 April 2025                [Page 20]
Internet-Draft                   FC-QUIC                    October 2024

   Key length: A var-int indicating the length of the security key.

   Key: Byte-sequence of the decryption key of the Flexicast 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.

   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 keys 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.

Navarre & Bonaventure     Expires 24 April 2025                [Page 21]
Internet-Draft                   FC-QUIC                    October 2024

   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.

13.  Security Considerations

   This section highlights security considerations when operating a
   Flexicast QUIC communication between a single source and multiple
   receivers.  Since a unique flexicast 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.  Malicious Receivers in a Flexicast Flow

   Malicious receivers may listen to a flexicast flow in the presence of
   healthy receivers.  This has several impacts that are addressed in
   this section.

13.1.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 state of
   the Flexicast QUIC source.  Since a Flexicast QUIC source can decide
   to unilaterally remove receivers from a flexicast flow, the source
   can decide to reject the FC_STATE JOINs from the malicious receiver.
   The source MAY send an FC_STATE frame withdrawing a flexicast 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 flexicast 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.

Navarre & Bonaventure     Expires 24 April 2025                [Page 22]
Internet-Draft                   FC-QUIC                    October 2024

13.1.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 flexicast flow.  By letting the source unilaterally
   decide to remove receivers from a flexicast flow, the impact of
   malicious receivers is limited.

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, "Multipath Extension for QUIC", Work
              in Progress, Internet-Draft, draft-ietf-quic-multipath-10,
              8 July 2024, <https://datatracker.ietf.org/doc/html/draft-
              ietf-quic-multipath-10>.

   [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
              QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9001>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc9000>.

Navarre & Bonaventure     Expires 24 April 2025                [Page 23]
Internet-Draft                   FC-QUIC                    October 2024

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/rfc/rfc8446>.

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,
              <https://doi.org/10.1109/65.819174>.

   [I-D.draft-krose-multicast-security]
              Rose, K. and J. Holland, "Security and Privacy
              Considerations for Multicast Transports", Work in
              Progress, Internet-Draft, draft-krose-multicast-security-
              06, 27 December 2023,
              <https://datatracker.ietf.org/doc/html/draft-krose-
              multicast-security-06>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-michel-quic-
              fec-01>.

   [I-D.jholland-quic-multicast-05]
              Holland, J., Pardue, L., and M. Franke, "Multicast
              Extension for QUIC", Work in Progress, Internet-Draft,
              draft-jholland-quic-multicast-05, 7 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-jholland-
              quic-multicast-05>.

Navarre & Bonaventure     Expires 24 April 2025                [Page 24]
Internet-Draft                   FC-QUIC                    October 2024

   [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, <https://datatracker.ietf.org/doc/html/draft-
              pardue-quic-http-mcast-11>.

   [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 pp. 1-12,
              DOI 10.1109/tnet.2024.3453759, 2024,
              <https://doi.org/10.1109/tnet.2024.3453759>.

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, DOI 10.17487/RFC1112, August 1989,
              <https://www.rfc-editor.org/rfc/rfc1112>.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
              <https://www.rfc-editor.org/rfc/rfc4607>.

   [RFC4654]  Widmer, J. and M. Handley, "TCP-Friendly Multicast
              Congestion Control (TFMCC): Protocol Specification",
              RFC 4654, DOI 10.17487/RFC4654, August 2006,
              <https://www.rfc-editor.org/rfc/rfc4654>.

   [RFC9002]  Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
              and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
              May 2021, <https://www.rfc-editor.org/rfc/rfc9002>.

   [RFC9293]  Eddy, W., Ed., "Transmission Control Protocol (TCP)",
              STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9293>.

   [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,
              <https://doi.org/10.1109/globecom38437.2019.9013401>.

Acknowledgments

   Louis Navarre is 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.

Navarre & Bonaventure     Expires 24 April 2025                [Page 25]
Internet-Draft                   FC-QUIC                    October 2024

   We thank Maxime Piraux for his review.

Authors' Addresses

   Louis Navarre
   UCLouvain
   Belgium
   Email: louis.navarre@uclouvain.be

   Olivier Bonaventure
   UCLouvain & WELRI
   Belgium
   Email: olivier.bonaventure@uclouvain.be

Navarre & Bonaventure     Expires 24 April 2025                [Page 26]