Flexicast QUIC: combining unicast and multicast in a single QUIC connection

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

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

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

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

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

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

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)

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

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

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

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

11. New Frames

All frames defined in this document MUST only be sent in 1-RTT packets.¶

If an endpoint receives a flexicast-specific frame in a different packet type, it MUST close the connection with an error of type FRAME_ENCODING_ERROR.¶

Receipt of flexicast-specific frames related to a Flexicast Flow ID that is not unknown by endpoint MUST be treated as a connection error of type FC_PROTOCOL_VIOLATION.¶

If an endpoint receives a flexicast-specific frame with a Flexicast Flow ID that it cannot process anymore (e.g., the 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 {
    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),
}

FC_STATE frame {
    Type (i) = TDB-01,
    Length (8),
    Flexicast Flow ID (8..160),
    Sequence number (i),
    Action (u64),
}

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),
}

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

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

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

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

Authors' Addresses