]> UCLouvain

Belgium louis.navarre@uclouvain.be

UCLouvain & WELRI

Belgium olivier.bonaventure@uclouvain.be

Transport QUIC quic multicast flexicast 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 Status information for this document may be found at . Discussion of this document takes place on the QUIC Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Starting from the initially efforts of Steve Deering , 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 , 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 or QUIC 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 . 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 and . To our knowledge, these extensions have not been fully implemented and deployed. Flexicast QUIC takes a different approach. Instead of extending QUIC , Flexicast QUIC extends 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 , we provide a brief overview of Flexicast QUIC in . We describe in more details the Flexicast QUIC handshake in and then the new QUIC frames in .

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 when, and only when, they appear in all capitals, as shown here.

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 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 . The source relies on an underlying IP multicast network to create an 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 ). 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 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.

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

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.

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. 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 ) 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. gives more details on the modifications to to protect packets sent on the flexicast flow.

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

The support of the flexicast extension is conditioned to the support of the multipath extension, as defined in . 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 . 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 .

Initialisation of a Flexicast Flow This section details how a Flexicast QUIC source advertises flexicast flows and how receivers join them. 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.

Flexicast flow announcement and join QUIC handshake FC_ANNOUNCE -------------> <------------- FC_STATE(JOIN) FC_KEY -------------> <------------- FC_STATE(LISTEN) ]]>

Flexicast Flow Announcement A Flexicast QUIC source announces a flexicast flow using the FC_ANNOUNCE frame (see ). Flexicast QUIC replaces the concept of Connection ID with the Flexicast Flow ID. Similarly to the Connection ID from , the Flexicast Flow ID uniquely identifies a flexicast flow. The Flexicast Flow ID MUST NOT be empty, as of 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 and , 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. 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.

Joining a Flexicast Flow 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 ). The receiver sends an FC_STATE frame with the Flexicast Flow ID of the flexicast flow it wants to join and the JOIN action.

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.

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.

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.

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 .

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.

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 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 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 , and to some extent 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 , 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 . 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 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.

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

Flow Control To be detailed in a future version of the document.

Packet protection Packet protection for QUIC version 1 is specified in . 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 .

Protection Keys This document extends the design from 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. 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 () 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.

Nonce Calculation expands the computation of the Nonce from 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.

Key Update TODO in a future version of the draft.

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

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 .

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

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 .

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

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

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 .

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

FC_KEY algorithms The algorithms and their encoding follow and {QUIC-TLS}. TODO: expand this section.

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 , , . 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 . 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 are applicable. For the latter, multicast specific congestion control mechanisms such as will be required. The current prototype uses a variant of the CUBIC congestion control.

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 . TODO: this section will be expanded in future versions of this document.

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.

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 to deal with it.

Intentionally Decreasing the Flexicast Flow Performance 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.

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
• TBD-01 for the FC_STATE frame defined in
• TBD-02 for the FC_KEY frame defined in

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

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document describes how Transport Layer Security (TLS) is used to secure QUIC. Alibaba Inc. Uber Technologies Inc. University of Mons (UMONS) UCLouvain and Tessares Private Octopus Inc. Ericsson This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/quicwg/multipath. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Akamai Technologies, Inc. TU Berlin This document defines a multicast extension to QUIC to enable the efficient use of multicast-capable networks to send identical data streams to many clients at once, coordinated through individual unicast QUIC connections. BBC Research & Development BBC Research & Development This document specifies a profile of the QUIC protocol and the HTTP/3 mapping that facilitates the transfer of HTTP resources over multicast IP using the QUIC transport as its framing and packetisation layer. Compatibility with the QUIC protocol's syntax and semantics is maintained as far as practical and additional features are specified where this is not possible. This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. Recommended procedure for IP multicasting in the Internet. This RFC obsoletes RFCs 998 and 1054. [STANDARDS-TRACK] IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. [STANDARDS-TRACK] This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. Institute of Electrical and Electronics Engineers (IEEE) UCLouvain UCLouvain, WEL RI This documents lays down the QUIC protocol design considerations needed for QUIC to apply Forward Erasure Correction on the data sent through the network. UCLouvain, Ottignies-Louvain-la-Neuve, Belgium WelRI, UCLouvain, Ottignies-Louvain-la-Neuve, Belgium Institute of Electrical and Electronics Engineers (IEEE) IEEE Akamai Technologies, Inc. Akamai Technologies, Inc. Interdomain multicast has unique potential to solve delivery scalability for popular content, but it carries a set of security and privacy issues that differ from those in unicast delivery. This document analyzes the security threats unique to multicast-based delivery for Internet and Web traffic under the Internet and Web threat models. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/squarooticus/draft-krose-multicast-security. This document specifies TCP-Friendly Multicast Congestion Control (TFMCC). TFMCC is a congestion control mechanism for multicast transmissions in a best-effort Internet environment. It is a single-rate congestion control scheme, where the sending rate is adapted to the receiver experiencing the worst network conditions. TFMCC is reasonably fair when competing for bandwidth with TCP flows and has a relatively low variation of throughput over time, making it suitable for applications where a relatively smooth sending rate is of importance, such as streaming media. This memo defines an Experimental Protocol for the Internet community. This document describes loss detection and congestion control mechanisms for QUIC.

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. We thank Maxime Piraux for his review.