QUIC Working Group M. Boucadair, Ed. Internet-Draft Orange Intended status: Informational O. Bonaventure, Ed. Expires: December 1, 2020 M. Piraux, Ed. Q. De Coninck UCLouvain S. Dawkins, Ed. Tencent America M. Kuehlewind, Ed. Ericsson M. Amend Deutsche Telekom A. Kassler Karlstad University Q. An Alibaba Group N. Keukeleire Tessares S. Seo Korea Telecom May 30, 2020 3GPP Access Traffic Steering Switching and Splitting (ATSSS) - Overview for IETF Participants draft-bonaventure-quic-atsss-overview-00 Abstract This document briefly presents the Access Traffic Steering, Switching, and Splitting (ATSSS) service being specified within the 3rd Generation Partnership Project (3GPP). The ATSSS service provides network support for multihomed devices to select a path for transmission (steer), move traffic from one path to another (switch), or use multiple paths simultaneously (split). TS 23.501 specifies an ATSSS architecture for TCP traffic. This document presents a snap-shot of the ongoing discussion in the 3GPP to enable ATSSS for non-TCP traffic, based on the use of QUIC, and assesses to what extent IETF specifications can be used to meet the ATSSS design goals. Apparent gaps are also documented. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Boucadair, et al. Expires December 1, 2020 [Page 1] Internet-Draft QUIC ATSSS May 2020 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 December 1, 2020. Copyright Notice Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Notes for Readers . . . . . . . . . . . . . . . . . . . . 4 2. Introduction to Access Traffic Steering, Switching, and Splitting (ATSSS) . . . . . . . . . . . . . . . . . . . . . . 4 3. Contribution and Discussion Venues for this draft. . . . . . 5 4. Conventions, Terminology, and Definitions . . . . . . . . . . 6 5. High Level ATSSS Overview . . . . . . . . . . . . . . . . . . 7 5.1. Reference Architecture . . . . . . . . . . . . . . . . . 7 5.2. External IP Addresses Used by the ATSSS UPF . . . . . . . 8 5.3. ATSSS Modes . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. ATSSS Rules . . . . . . . . . . . . . . . . . . . . . . . 9 6. ATSSS Phases . . . . . . . . . . . . . . . . . . . . . . . . 11 7. ATSSS Phase 1: Support for TCP . . . . . . . . . . . . . . . 11 7.1. ATSSS Phase 2: Adding Non-TCP Support . . . . . . . . . . 13 7.1.1. QUIC and Multihoming . . . . . . . . . . . . . . . . 14 7.1.2. QUIC as an ATSSS Data Plane Protocol . . . . . . . . 15 7.1.3. Single QUICv1 Tunnel with Unreliable Datagram Extension and Connection Migration . . . . . . . . . 15 7.1.4. Multiple QUICv1 Tunnels with Unreliable Datagram Boucadair, et al. Expires December 1, 2020 [Page 2] Internet-Draft QUIC ATSSS May 2020 Extension and Connection Migration . . . . . . . . . 17 7.1.5. MP-QUIC Tunneling . . . . . . . . . . . . . . . . . . 18 7.2. Mapping of Both TCP and Non-TCP to QUIC Streams and Datagrams . . . . . . . . . . . . . . . . . . . . . . . . 19 7.3. Encapsulation Overhead . . . . . . . . . . . . . . . . . 20 7.4. Multiple Encryptions . . . . . . . . . . . . . . . . . . 21 7.5. Congestion Control in Congestion Control and Coexistence 21 7.6. Packet Order Reconstruction for (MP-)QUIC Splitting Mode 22 8. QUICv1 Gap Analysis for ATSSS Phase 2 . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 12. Document History . . . . . . . . . . . . . . . . . . . . . . 24 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 13.1. Normative References . . . . . . . . . . . . . . . . . . 24 13.2. Informative References . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction The 3rd Generation Partnership Project (3GPP) has described the Access Traffic Steering, Switching, and Splitting (ATSSS) service, used to carry traffic over multiple available paths. In Release 16 [TS23501], ATSSS supports TCP traffic relying upon two IETF protocols: MPTCP [RFC6824] and Convert Protocol [I-D.ietf-tcpm-converters]. As part of preparation for Release 17 studies, 3GPP has expressed an interest in other IETF protocols and protocol extensions that would enable ATSSS service of traffic not supported by the Convert Protocol nor based on the use of MPTCP. To that aim, 3GPP has contacted the IETF through a formal liaison [atsssliaison], letting the IETF know about this interest. An excerpt of the liaison document is provided below: "The work on the study has not yet started in 3GPP, and there are thus no agreed conclusions. The goal is to enable steering, switching and splitting of traffic (primarily UDP) across multiple accesses, including latency sensitive and real time traffic. Therefore 3GPP is interested to receive regular feedback on progress and prioritization on the multipath extensions to QUIC." Because "3GPP SA kindly requests IETF to take the above information into account when discussing future work in prioritizing the multipath work for QUIC", but the complete specification of ATSSS in the relevant 3GPP architecture documents reflects the complexity of 3GPP networks, the authors of this document worked to provide a high level overview of the parts of ATSSS that would be impacted by IETF Boucadair, et al. Expires December 1, 2020 [Page 3] Internet-Draft QUIC ATSSS May 2020 protocol design, in terminology that is more familiar to IETF participants. 1.1. Notes for Readers We provide a high-level overview of ATSSS in Section 5, describe the current ATSSS version in Section 7, describe our thoughts about a QUIC-based version of ATSSS in Section 7.1, and conclude with our understanding of the gaps between QUIC version 1 and what a QUIC- based version of ATSSS will require in Section 8. This document is an informational Internet-Draft from individuals, and does not carry any special status within the IETF. This document abstracts considerable architectural detail that is available in 3GPP specifications. The goal is to make this overview more accessible for IETF readers who are not familiar with 3GPP 5G architecture. This document makes references to Internet-Drafts that are not as mature as the core QUIC Internet-Drafts, and in some cases, have not been adopted as Working Group drafts yet, although all are within existing and proposed IETF working group charters. The goal is to give 3GPP readers the most up-to-date understanding of what is possible. 2. Introduction to Access Traffic Steering, Switching, and Splitting (ATSSS) Mobile devices such as laptops, smartphones, tablets support multiple network interfaces that may attach to different networks. Over the years, various techniques have been proposed to support such multi- interfaced devices (e.g., Shim6 [RFC5533], Mobile IPv6 [RFC6275], Proxy Mobile IPv6 [RFC5213], or Multipath TCP [RFC6824]). Users of these devices have different expectations concerning the utilization of available network connectivity (and thus their different network interfaces). For simplicity, we consider a smartphone that is equipped with a Wireless LAN (WLAN) interface and a cellular interface, but the discussion below can be generalized to any device with multiple network interfaces that support IP. Some users of these smartphones want to offload most or all of their traffic onto the WLAN when the WLAN is available while expecting seamless handovers when it is not available. For example, when they move out of the reach of their home WLAN, they expect that the established flows (e.g., TCP connections, UDP flows) will continue over the cellular interface without any interruption (called "session Boucadair, et al. Expires December 1, 2020 [Page 4] Internet-Draft QUIC ATSSS May 2020 continuity" in 3GPP). As the devices are assigned different IP addresses over WLAN and the cellular networks, this seamless handover requires some specific assistance from the network. The current utilization of Multipath TCP on Apple smartphones is an example of this use case [IETFJ16]. Other users want to load balance their flows over the different available networks, e.g., by sending a delay-sensitive flow over cellular and a long download over the WLAN network. Several smartphones enable applications to indicate their preferences when using available networks. This steering policy can be managed by the smartphone, but flows need to continue after a handover. Still other users may want to combine the resources provided by the cellular and the WLAN networks to improve the up and download throughput performance of individual flows. The GiGA LTE and GiGA 5G services deployed using Multipath TCP in South Korea are examples of this use case [IETFJ16]. To support these different use cases in 5G networks, 3GPP is defining the Access Traffic Steering, Switching and Splitting (ATSSS) service [TS23501]. This work is further adopted by the Broadband Forum to provide similar capabilities to residential gateways equipped with multiple access interfaces, in the continuity of the Hybrid Access Networks [TR-348]. In this document, we abstract many of the technical details of future 5G networks to explain the capabilities ATSSS needs, which may impact decisions about future work on IETF protocols. 3. Contribution and Discussion Venues for this draft. (Note to RFC Editor - if this document ever reaches you, please remove this section) This document is under development in the Github repository at https://github.com/obonaventure/draft-quic-atsss-reqs. Readers are invited to open issues and send pull requests with contributed text for this document. Substantial discussion of this document should take place on the QUIC working group mailing list (quic@ietf.org). Subscription and archive details are at https://www.ietf.org/mailman/listinfo/quic. Boucadair, et al. Expires December 1, 2020 [Page 5] Internet-Draft QUIC ATSSS May 2020 4. Conventions, Terminology, and Definitions This document makes use of 3GPP specific terms defined in [RFC6459], mainly the following ones: o Packet Data Network (PDN): is a packet-based network that either belongs to the operator or is external (such as the Internet or a corporate intranet). The user eventually accesses services in one or more PDNs. The operator's packet core networks are separated from packet data networks by User Plane Functions (UPFs). o UE (User Equipment): refers to the devices that are hosts with the ability to obtain Internet connectivity via a 3GPP network. o User Plane: refers to data traffic and the required sessions for the data traffic. In practice, IP is the only data traffic protocol used in the user plane. Also, the document uses the following additional terms: o Protocol Data Unit (PDU) Session: An association between the UE and the Data Network (DN) to carry the user data/traffic. o PDU Connectivity Service: A service that provides exchange of PDUs between an UE and a Data Network. o Multi-access PDU (MA-PDU) Session: A PDU session that has simultaneously user plane resources assigned on 3GPP and non-3GPP access networks. o User Plane Function (UPF): A logical function in the 5G core network that provides the interconnect point between the mobile infrastructure and the Data Network (DN) and anchor point for Protocol Data Unit (PDU) Sessions to enable mobility. o Data Network Name (DNN): is a Fully Qualified Domain Name (FQDN) and resolves to a set of gateways in an operator's network. DNN is used for the selection of the UPF(s) for a PDU Session. o 5G Core (5GC) network: Refers to the part of the 5G System which is independent of the access technology used by an UE (e.g., cellular, WLAN) [TS23501]. A 5G Core network can be reached via one or more access networks. o 3GPP access network: Refers to a radio access network used by an UE to reach a 5G Core network. In such case, the UE uses an access technology that is specified by 3GPP. Boucadair, et al. Expires December 1, 2020 [Page 6] Internet-Draft QUIC ATSSS May 2020 o Non-3GPP access network: Refers to an access network (e.g., WLAN) that is not a 3GPP access network and which is used by an UE to connect to a 5G Core network. o 5G control plane: Denotes the 5G control management component of use plane resources (e.g., forwarding policies). 5. High Level ATSSS Overview The 5G Core supports a service that provides exchange of data between a User Equipment (UE) and a data network (referred to as Packet Data Network (PDN)) identified by a Data Network Name (DNN). This connectivity service, called the Protocol Data Unit (PDU) Connectivity Service, is realized via 'PDU Sessions' that are established upon request from User Equipment (UE) when the UE first connects to that network. The type of PDU Session can be IPv4, IPv6, IPv4v6, Ethernet or Unstructured. It is out of the scope of this document to provide a comprehensive overview of 5G System (5GS) architecture. In particular, this document does not describe how PDU Sessions are established, and thus how IP addresses/prefixes are assigned to requesting UEs. An UE can be provided a multi-access PDU Connectivity Service. That is, an UE can exchange data with a PDN by using a "3GPP access network" and a "non-3GPP access network" (often a WLAN). This is realized using the ATSSS service that is provided in the 5G core network control plane and user plane. The user plane part of the ATSSS functionality is contained in the User Plane Function (UPF) that manages the UE's PDU session. 5.1. Reference Architecture To understand the operation of the ATSSS service, it is useful to consider the reference environment shown in Figure 1. An UE is attached to two different access networks (Access Net A and Access Net B). Each of these two networks is potentially shared with other users, so the bandwidth available from each network varies over time. These fluctuations in bandwidth are managed by using congestion control schemes. One of these access networks is managed by a 5G provider according to the 3GPP specifications. The second network is potentially managed by a different organization. It is important to note that in this second case, there is an IPSec tunnel between the UE and a dedicated device in the 5G network (not shown in Figure 1). A dedicated IP address is assigned by means of Internet Key Exchange version 2 (IKEv2) to the UE to access the 5G Core via this second network. Boucadair, et al. Expires December 1, 2020 [Page 7] Internet-Draft QUIC ATSSS May 2020 The UE interacts with a distant server through a User Plane Function hosting the ATSSS functionality. This UPF is called hereafter ATSSS UPF. The ATSSS UPF enables the UE to use a transport protocol that supports the different access networks even if the server does not support it (i.e., does not use a multipath-capable transport protocol). The 5G control plane provides the UE and the ATSSS UPF with rules as discussed in Section 5.4. Note that, as per 3GPP definition, the rules provided to the UE are called ATSSS Rules, while the ATSSS information provided to the UPF is carried via Multi-Access Rules, but for simplicity this document uses the term "ATSSS rules" for the ATSSS information provided to both UE and UPF. ........(ATSSS Rules From Network)........ . . . ------------ . . / \ . . +-------| Access Net A |--+ . . | \ (3GPP) / | . . | ------------ | . . | | . . | | . +---+--+ | +-----+ | | +--------|ATSSS| +------+ | UE | | |-/.../--|Server| | | +--------| UPF | +------+ +---+--+ | +-----+ | | | | | ------------ | | / \ | +-------| Access Net B |--+ \ (non 3GPP) / ------------ Figure 1: Simplified Reference Architecture for ATSSS 5.2. External IP Addresses Used by the ATSSS UPF Depending on the ATSSS mode, the ATSSS UPF may translate the access network specific addresses into an address called the Multi-Access (MA) IP address and vice versa. Such an address is also directly assigned to the UE (that is, packets that are not eligible for the ATSSS service are sourced by the UE with that IP address). Absent any coordination between the UE and the ATSSS UPF (e.g., assignment of port ranges), the same IP address and port number could Boucadair, et al. Expires December 1, 2020 [Page 8] Internet-Draft QUIC ATSSS May 2020 be used simultaneously by the ATSSS UPF and the UE; which is problematic. To avoid such issue, the ATSSS UPF may be configured with a pool of IP addresses that it can use in the Internet-facing interfaces instead of preserving the MA IP address assigned to the UE. How that pool is used is deployment- and implementation-specific. 5.3. ATSSS Modes 3GPP defines the following procedures [TS23501] that are applicable between "3GPP access" and "non-3GPP access" networks: o Access Traffic Steering: selection of an access network for a new data flow and the transfer of the traffic of that data flow over the selected access network. o Access Traffic Switching: migration of all packets of an ongoing data flow from one access network to another access network. Only one access network is in use at a time, but this still ensures session continuity. o Access Traffic Splitting: forwarding the packets of a data flow across multiple access networks simultaneously. Techniques to provide ATSSS are classified by the 3GPP into two flavors: (1) higher-layer techniques which operate above the IP layer (e.g., MPTCP), and (2) lower-layer techniques which operate below the IP layer. 5.4. ATSSS Rules The 5G control plane provides the UE and the ATSSS UPF with rules that specify which flows are eligible to the ATSSS service (i.e., by mapping them to a Multi-Access PDU Session). Once a Multi-Access PDU Session has been established, a set of rules are then delivered to both the UE and the ATSSS UPF in order to enable consistent treatment of the flows by both the UE and the ATSSS UPF within the Session. The traffic that matches an ATSSS rule can be distributed among the available access networks following one of these modes: o "Active-Standby": The traffic associated with the matching flow will be forwarded via a specific access (called 'active access') and switched to another access (called 'standby access') when the active access is unavailable. Boucadair, et al. Expires December 1, 2020 [Page 9] Internet-Draft QUIC ATSSS May 2020 o "Smallest Delay": The traffic associated with the matching flow will be forwarded via the access that presents the smallest RTT. To that aim, specific measurements are conducted by the UE and a dedicated function co-located with the ATSSS UPF. o "Load-Balancing": The traffic associated with the matching flow will be distributed among the available access networks following a distribution ratio (e.g., 30% via a first access, 70% via a second access). o "Priority-based": For this mode, accesses are assigned priority levels that indicate which access to be used first. Concretely, the traffic associated with the matching flow will be steered on the access with a high priority till congestion is detected, then the overflow will be forwarded over a low priority access. In order to provide the above-mentioned steering modes, measurement information about the current network state of each path is needed. Often if a multipath capable protocol is used, the measurements are available as part of the protocol itself. For ATSSS approaches where this is not the case, a dedicated protocol called Performance Measurement Function (PMF) protocol can be used. This protocol is enabled between the UE and the UPF in order to provide RTT measurements and report access availability/unavailability by the UE to the UPF. These modes of operations can be met by using multipath protocols such as MPTCP [RFC6824] to select the different paths between the UE and the ATSSS. Such protocols usually include two types of mechanisms to control the utilization of the paths: (i) a path manager and (ii) a packet scheduler [RFC8041]. The path manager decides when a new subflow needs to be established over a path while the packet scheduler selects the subflow over which the next packet will be sent. A more detailed description of several packet schedulers may be found in [I-D.bonaventure-iccrg-schedulers]. The "Active-Standby" mode can be implemented using a path manager that tries to use the active access and switches to the standby one after a certain number of retransmissions. This mode of operation is similar to the utilization of Multipath TCP on iOS smartphones [RFC8041]. The "Smallest Delay" mode can be implemented using a path manager that establishes a subflow over both paths and a packet scheduler that measures their RTTs and prefers the one having the lowest RTT. These path manager and scheduler are similar to those used by Multipath TCP on Linux [RFC8041]. Boucadair, et al. Expires December 1, 2020 [Page 10] Internet-Draft QUIC ATSSS May 2020 The "Load-Balancing" mode would use the same path manager with a weighted round-robin scheduler. The "Priority-based" mode can be implemented using a path manager that is similar to the one used by the "Active-Standby" one, but which reacts faster and a packet scheduler that prefers the high priority path. These path manager and scheduler are similar to the ones used in deployed Hybrid Access networks [Hybrid]. 6. ATSSS Phases We first describe in Section 7 ATSSS as specified in Release 16 (called hereafter, ATSSS Phase 1) that uses Multipath TCP [RFC6824] and the 0-RTT Convert Protocol [I-D.ietf-tcpm-converters] to handle TCP traffic. We then discuss in Section 7.1 the data plane requirements for Phase 2 of the ATSSS specification that 3GPP plans for Release 17. More details about 3GPP releases can be found at: https://www.3gpp.org/specifications/Releases. 7. ATSSS Phase 1: Support for TCP For ATSSS with Multipath TCP functionality, a client with two interfaces connected to two disjoint access networks (in this case, Access Net A and Access Net B) uses MPTCP to reach an MPTCP proxy over either, or both, of the access networks. This allows the client to communicate with a server which does not support MPTCP. During the attachment of an ATSSS-capable UE to the network, the UE may retrieve the MPTCP proxy information: an IP address, a port number, and the type of proxy. In the current release, the mandatory MPTCP proxy type is the "Transport Converter" [I-D.ietf-tcpm-converters]. Also, both the MPTCP Client and MPTCP proxy are configured with ATSSS rules from the network that govern how the multiple network paths between the MPTCP Client and MPTCP proxy are used. This relationship is shown using "." between the MPTCP Client and MPTCP Proxy in Figure 2. Boucadair, et al. Expires December 1, 2020 [Page 11] Internet-Draft QUIC ATSSS May 2020 ........(ATSSS Rules From Network)........ . . . ------------ . . / \ . . +-------| Access Net A |--+ . . | \ (3GPP) / | . . | ------------ | . . | | . +------+ | +-----+ |MPTCP | +--------|MPTCP| +------+ | | | |=/.../==|Server| |Client| +--------|Proxy| +------+ +--+---+ | +-----+ | | | ------------ | | / \ | +--------| Access Net B |--+ Legend: \ (non 3GPP) / --- MPTCP subflow ------------ === Proxied TCP flow Figure 2: Simplified Reference Architecture for ATSSS with Multipath TCP An ATSSS-capable UE can make use of the MPTCP functionality by establishing MPTCP-assisted connections via the MPTCP proxy relying upon the Convert Protocol [I-D.ietf-tcpm-converters]. The UE behaves as a "Client", while the MPTCP proxy behaves as a Transport Converter [I-D.ietf-tcpm-converters]. The UE then sends packets bound to connections matching an ATSSS rule to the provisioned Transport Converter and destination port number. Concretely, the UE initiates the MPTCP connection towards the Transport Converter and indicates the IP address and port number of the Server within the connection establishment packet (i.e., in the payload of the SYN sent to the Transport Converter). Doing so enables the Transport Converter to immediately initiate a connection towards that Server, without experiencing an extra delay. The Transport Converter waits until the receipt of the confirmation that the Server agrees to establish the connection before confirming it to the Client. A flow example of an MPTCP-proxied connection is shown in Figure 3. This example assumes that the Server is not MPTCP-aware. The instructions included in the matching ATSSS rule will be followed for the management of the MPTCP connection (including the selection of the access network to establish the first subflow). Boucadair, et al. Expires December 1, 2020 [Page 12] Internet-Draft QUIC ATSSS May 2020 UE MPTCP Proxy Server | | | |SYN, MPC [->Server:port]| SYN, MPC | |----------------------->|----------------------->| |<-----------------------|<-----------------------| | SYN+ACK, MPC [...] | SYN+ACK | |----------------------->|----------------------->| | ACK, MPC | ACK | | ... | ... | Legend: []: Convert Protocol TLVs MPC: MP_CAPABLE option [RFC6824] Figure 3: An Example of MPTCP-proxied Connection Matching an ATSSS Rule. This approach provides 0-RTT (Zero Round-Trip Time) conversion service since no extra delay is induced by the Convert protocol compared to connections that are not proxied. Also, the Convert Protocol does not require any encapsulation (so, no tunnels). The UE and the MPTCP proxy track the performance of the access networks by leveraging MPTCP's internal mechanisms including congestion control and round-trip-time measurements. MPTCP uses this performance information to support splitting and switching. If the server supports MPTCP, the Convert Protocol provides an option for clients to "opt-out". In such case, an MPTCP connection is directly established between the client and the server. Given that few servers are MPTCP capable, relying on the ATSSS service is the only option for UEs to make use of available multiple paths to most servers simultaneously. 7.1. ATSSS Phase 2: Adding Non-TCP Support The MPTCP-based ATSSS approach discussed in the previous section is specific to TCP, obviously. Therefore it does not support non-TCP traffic, such as UDP, QUIC [QUIC-Deployment] or IPsec and Datagram Transport Layer Security (DTLS) Virtual Private Network (VPN) services. As the share of these protocols grows, mainly driven by QUIC deployment, a future ATSSS needs to extend beyond supporting TCP only. The seamless handover provided by ATSSS is particularly useful for real-time traffic (e.g., voice or video calls), Several proposals to carry non-TCP traffic have been discussed, including using TCP [I-D.boucadair-mptcp-plain-mode] or defining Boucadair, et al. Expires December 1, 2020 [Page 13] Internet-Draft QUIC ATSSS May 2020 multipath extensions to DCCP [I-D.amend-tsvwg-multipath-dccp]. The work within 3GPP now focuses on using QUIC as the baseline for ATSSS Phase 2. 7.1.1. QUIC and Multihoming For non-TCP traffic, QUIC is already the dominant part of UDP traffic. A solution as realized with the Convert Protocol for (MP)TCP is not possible for QUIC as a QUIC connection cannot be intercepted and converted as in the ATSSS architecture for (MP)TCP (Figure 2). For (MP)TCP only the transport protocol (TCP) is intercepted, while transport security provided by Transport Layer Security (TLS) on top of TCP stays in tact. For QUIC transport, security is integrated into the transport protocol and thus cannot be intercepted. Some ATSSS modes can be natively supported by the base QUIC specification for QUIC flows. For example, the "Active-Standby" and "Smallest Delay" steering modes can be supported directly between an UE and a QUIC server without any assistance from the network other than the performance measurement information. Further, QUIC provides a feature called connection migration (Section 9 of [I-D.ietf-quic-transport]) that makes it possible to move a QUIC connection from one path/IP address to another without terminating and reestablishing the connection. Connection migration can further enable traffic switching but does not support traffic splitting as only one path can be used simultaneously. An extension to QUIC to support simultaneous use of multiple paths is proposed in [I-D.deconinck-quic-multipath]. However, similar to a native MPTCP connection, a (MP)QUIC connection initiated between the UE and a server without the ATSSS UPF assistance cannot benefit from any direct application of the ATSSS steering methods based on network input given that the steering policy as currently defined in ATSSS is local to the UE and the ATSSS UPF and there are no means to signal that policy to a remote server. Network input can be especially beneficial for cases such as: o avoiding unnecessary use of user quota if one of the access networks is subject to volume-based quota. o avoiding frequent connection migration if both access networks could be used to forward packets (each with a distinct source IP address). Boucadair, et al. Expires December 1, 2020 [Page 14] Internet-Draft QUIC ATSSS May 2020 7.1.2. QUIC as an ATSSS Data Plane Protocol This section elaborates how non-TCP traffic (UDP or a subset like QUIC) can be encapsulated into a tunnel between the UE and the ATSSS UPF to enable ATSSS for all traffic, not only TCP or QUIC. This section discusses to what extent QUIC can be used as a tunneling protocol for the ATSSS service and whether gaps are found. When tunneling non-TCP (e.g., UDP, IP) over QUIC the Unreliable Datagram Extension [I-D.ietf-quic-datagram] can be used. Each data packet would be transported unreliably as a datagram over a QUIC connection. Transporting these datagrams unreliably as would be done in IPsec or DTLS-based tunnels is especially important for flows that do not require reliable delivery and would suffer from unnecessary delays caused by the retransmissions used to support reliability. QUIC datagrams are congestion-controlled, but since the latency between the UE and the ATSSS UPF is small compared to the end-to-end latency, having second, local, congestion control loops should not impact the end-to-end congestion control negatively. This document discusses three approaches: o Use of QUIC version 1 with the Unreliable Datagram Extension Section 7.1.3 o Use of QUIC version 1 with the Unreliable Datagram Extension but with one QUIC connection over each access network Section 7.1.4 o Use of a single Multipath QUIC connection [I-D.deconinck-quic-multipath], with the Unreliable Datagram Extension, over all access networks Section 7.1.5. 7.1.3. Single QUICv1 Tunnel with Unreliable Datagram Extension and Connection Migration Boucadair, et al. Expires December 1, 2020 [Page 15] Internet-Draft QUIC ATSSS May 2020 ------------ *---------/ \---------* |........| Access Net A |........| |:*-------\ (3GPP) /-------*:| |:| ------------ |:| |v| |:| +--+-+-+ +--+-+-+ |QUIC | |QUIC | +------+ | | | |.......>|Server| |Client| |Proxy | +------+ +------+ +------+ ------------ / \ | Access Net B | Legend: \ (non 3GPP) / --- QUIC tunnel connection ------------ ... Tunneled non-TCP flow Figure 4: Single QUICv1 tunnel QUIC can be used as a tunneling protocol between the UE and the ATSSS UPF. Use of the Unreliable Datagram Extension avoids unnecessary delays due to local retransmissions and, more important, subsequent head-of-line blocking. In this case, there is (only) one QUIC connection between the UE and the ATSSS UPF for a given flow. And as such, that QUIC connection uses only one access network at a time. However, given the connection migration capability of QUIC, the QUIC connection could be moved to another access network, e.g., when the network indicates that the currently used access network would go away or that its capacity becomes limited. The UE can then initiate the connection migration to start the path validation process as specified in Section 9 of [I-D.ietf-quic-transport]. When, and how, to switch over depends on the rules provided by the network (Section 5.4) and the performance measurements that are accessible to both the UE and the ATSSS UPF. Note that connection migration can only be at the initiative of the UE as per Section 9 of [I-D.ietf-quic-transport]. This means that the UPF cannot make use of a second access network upon failure or degradation observed on a first access network. It is thus possible to support the switching and steering functions of ATSSS, but splitting cannot be supported. Path validation induces a delay when switching as packets are buffered. Further, congestion control state is reset on a new path and needs to ramp up. When frequent handovers happen, splitting traffic over multiple paths simulaneously can be beneficial for a Boucadair, et al. Expires December 1, 2020 [Page 16] Internet-Draft QUIC ATSSS May 2020 smooth user experience. Further, of course, the ability to use multiple paths simultaneously also increases the maximum capacity available, which can also be beneficial in some cases. This option is not considered a valid approach for the ATSSS Phase 2 discussed within 3GPP. 7.1.4. Multiple QUICv1 Tunnels with Unreliable Datagram Extension and Connection Migration ------------ *---------/ \---------* |........| Access Net A |........| |:*-------\ (3GPP) /-------*:| |:| ------------ |:| |v| |:| +--+-+-+ +--+-+-+ +------+ |QUIC | |QUIC |......>| | | | | | |Server| |Client| |Proxy |......>| | +--+-+-+ +--+-+-+ +------+ |^| |:| |:| ------------ |:| |:*-------/ \-------*:| |........| Access Net B |........| Legend: *---------\ (non 3GPP) /---------* --- QUIC tunnel connection ------------ ... Tunneled non-TCP flow Figure 5: Traffic steering of two end-to-end flows using multiple QUICv1 tunnels Another approach is to use one QUIC connection over each access network. In this case, there are multiple QUIC connections that are used as tunnels from the UE to the ATSSS UPF to transport traffic that belongs to one or multiple flows. The UE and ATSSS UPF need to select one QUIC connection to forward each application data packet, based on the rules provided by the network. This approach can support steering (by selecting just one QUIC connection for each flow), switching (by moving flows from one QUIC connection to another) as well as splitting when both tunnels are used simultaneously for different packets of the same flow. However, this approach for splitting is challenging since data from the same flow are sent over different QUIC connections, again using unreliable datagram to minimize head-of-line blocking. Because both these QUIC connections are completely independent of each other and the paths on the different access networks may have different Boucadair, et al. Expires December 1, 2020 [Page 17] Internet-Draft QUIC ATSSS May 2020 latency, this approach would likely result in reordering of packets that belong to a split flow. If reordering should be avoided, this would require additional signaling between the UE and the ATSSS UPF, e.g., adding sequence numbers, and adding a reordering buffer and logic to both the UE and ATSSS UPF. Furthermore, since the bandwidth available for each QUIC connection varies as a function of the congestion experienced over each access network, data sent over a congested connection could delay the delivery of subsequent data over another connection. Experience with MPTCP on smartphones shows that its integrated mechanisms (e.g., congestion control, round-trip-time estimation, packet scheduler) are well suited to support splitting and switching. Providing a similar service over independent QUIC connections would require a complex application that would need to track the congestion window, round-trip-time, and loss characteristics of the underlying QUIC connections as well as some specific application layer signalling to glue the various QUIC connections together. 7.1.5. MP-QUIC Tunneling ------------ *---------/ \---------* | . . . .| Access Net A |. . . . | |.*-------\ (3GPP) /-------*.| | | ------------ | | |.| |.| +--+-+-+ +--+-+-+ +------+ |MPQUIC| |MPQUIC| | | | | | |......>|Server| |Client| |Proxy | | | +--+-+-+ +--+-+-+ +------+ |.| |.| | | ------------ | | |.*-------/ \-------*.| | . . . .| Access Net B |. . . . | Legend: *---------\ (non 3GPP) /---------* --- MPQUIC subflow ------------ ... Tunneled non-TCP flow Figure 6: Traffic splitting using a Multipath QUIC tunnel A third candidate solution is to leverage the ability of QUIC to support multiple streams and the Unreliable Datagram Extension, and to extend it with Multipath capabilities as described in [I-D.deconinck-quic-multipath]. Boucadair, et al. Expires December 1, 2020 [Page 18] Internet-Draft QUIC ATSSS May 2020 In this case, there is a single (Multipath) QUIC connection between the UE and the ATSSS UPF. With a multipath transport, splitting is naturally supported. Data sent over one access network can be retransmitted over the other if the first becomes congested. Some measurements and simulations have shown that Multipath QUIC provides similar performance as Multipath TCP when combining different access networks [MPQUIC-Conext]. Steering can be also supported, similarly to MPTCP. The path scheduler can map datagrams carrying an entire flow to one or another access network based on the provided rules. Switching can be improved by splitting traffic simultaneously over both links such that the congestion window of the new path can be open before the old path goes away. This makes handovers smoother. Experience with Multipath TCP on smartphones has shown that handovers are not a binary process. When a smartphone performs handovers, there are frequently short periods of time during which both networks are imperfect [MPTester]. Using use both networks simultaneously during these periods, improves user experience. Furthermore, traffic can be better distributed among available paths based on available resources if one of the access networks fails or begins to become congested. 7.2. Mapping of Both TCP and Non-TCP to QUIC Streams and Datagrams In ATSSS Phase 1, each TCP connection originated by the UE corresponds to one MPTCP connection that is terminated on the ATSSS UPF. With ATSSS Phase 2 using MPQUIC as a tunneling protocol, one can leverage the multi-stream capability of QUIC to carry the bytestreams of multiple TCP connections over a single MPQUIC session. Focusing on the case where the UE maintains one QUIC connection with its ATSSS UPF, every TCP connection that it creates results in the creation of a new stream of the MPQUIC connection with the ATSSS UPF. Similarly the ATSSS UPF can map each incoming TCP connection from a remote host onto a stream of the MPQUIC connection. This is illustrated in Figure 7. Stream mapping is most beneficial for TCP, as it avoids reordering and TCP anyway requires in-order delivery. It is more appropriate to use QUIC with the Unreliable Datagram Extension for all other traffic. Boucadair, et al. Expires December 1, 2020 [Page 19] Internet-Draft QUIC ATSSS May 2020 AAAAAA ===========> +-------+ // +---------|Server2| || | | | \/ | +-------+ +------+ MPQUIC session +-----+ | | <------------------------------>| | +-------+ | U E | Stream1 AAAAAAAAAAAAA...AAA |ATSSS|-/.../--|Server1| | | Stream2 BBBBBBBBBBBBB...BBB | UPF |<======>| | | | <------------------------------>| | BBBBBB +-------+ +------+ +-----+ <----> MPQUIC session <====> TCP connection Figure 7: ATSSS Phase 2 Maps Each TCP Connection on a Stream of the MPQUIC Connection Between the UE and the ATSSS UPF Two application layer protocols are proposed to manage the mapping of TCP connections to QUIC streams as well as the transmission of UDP datagrams over QUIC datagrams: (1) The proposed masque working group (wg) extends the HTTP/3 CONNECT method with a UDPCONNECT method to use QUIC as a tunnel for UDP traffic [I-D.schinazi-masque-connect-udp]. Another use case in scope for masque wg is IP proxying which can be used for tunneling and forwarding of TCP connections [I-D.schinazi-masque-protocol]. (2) QUIC Tunnel is a close proposal providing similar functionalities to MASQUE based on a binary protocol [I-D.piraux-quic-tunnel][I-D.piraux-quic-tunnel-tcp], and focusing on the ATSSS use case. Both proposals rely upon single QUIC connections and inherit thus the same issues discussed in Section 7.1.3 and Section 7.1.4. 7.3. Encapsulation Overhead In 3GPP architectures, a variety of encapsulations are already used to carry user data. The use of QUIC as a tunneling method for ATSSS will add some additional overhead. When the user data is forwarded over a non-3GPP network access, this overhead comes further in addition to an IPsec tunnel between the UE to the 5G Core Network which is already at least 142 octets for an IPv6 packet forwarded over a non-3GPP network access. In contrast, the MPTCP based mechanism in ATSSS Phase 1 does only add a minor overhead during Boucadair, et al. Expires December 1, 2020 [Page 20] Internet-Draft QUIC ATSSS May 2020 connection establishment, but no additional overhead during the rest of the connection. More investigation is required to assess whether the ATSSS Phase 2 overhead is an issue. Solutions to optimize that overhead could be considered, if needed. 7.4. Multiple Encryptions The use of QUIC as a tunneling protocol in ATSSS will add an additional layer of encryption. As there is already encryptions on other layers (e.g., IP Encapsulating Security Payload (ESP)) this leads to multiple layers of encryption, which might be redundant. Such multiple encryptions will have performance implications on the UE, in particular. Means to optimize the various redundant encryptions are for further investigation in 3GPP. 7.5. Congestion Control in Congestion Control and Coexistence Many applications that are sending unreliable traffic use various congestion control algorithms to detect congestion and adjust their sending rate based on inferred end-to-end latency and loss characteristics. Examples include Adaptive Video Streaming using e.g. SCREAM [RFC8298], or other media streaming applications that use QUIC as transport layer. When using QUIC version 1 with Unreliable Datagram Extension or Multipath QUIC as ATSSS solution, this leads to nested congestion control, where both inner and outer congestion control coexist. When using Multiple QUICv1 tunnels with Unreliable Datagram Extension or MP-QUIC tunneling, the packet scheduler could have an additional impact on the perceived end-to-end latency and loss due to the potential difference of the individual path characteristics. When deploying ATSSS Phase 1 and Phase 2 in parallel, with the UE serving both reliable and unreliable flows, different congestion control algorithms may coexist on individual paths, which may lead to fairness issues or even meltdown effects. We recognize that nested congestion control mechanisms (such as QUIC encapsulated in QUIC or SCREAM encapsulated in QUIC) as well as the coexistence of ATSSS Phase 1 and Phase 2 have implications that require further study. Boucadair, et al. Expires December 1, 2020 [Page 21] Internet-Draft QUIC ATSSS May 2020 7.6. Packet Order Reconstruction for (MP-)QUIC Splitting Mode Both tunnel solutions in Section 7.1.4 and Section 7.1.5 allow the splitting mode for simultaneously sending data over multiple paths. In this case packet reordering can occur when a QUIC tunnel communication is split across paths with very different latencies. Generally, applications have to deal with packet reordering, since the best effort for Internet traffic has no guarantee to prevent it. However, in practice, packet reordering in the network is assumed to be very limited. Applications that require in-order delivery and e.g. rely on TCP or implement a similar mechanism itself can be sensitive to high amounts of reordering and experience decreased performance. As such it is desirable that the respective receiver side of the tunnel termination points has the ability to reconstruct the original packet ordering. While in the case when using the MPTCP converter, losses are retransmitted quickly on the local segment, when the Unreliable Datagram Extension for QUIC is used, the reconstruction mechanism has to further account for packet loss which may occur for any of the paths within the QUIC tunnel. This can cause delays in the reordering logic, which in turn can have a negative impact on applications that do not require in-order delivery, such as real-time transmissions. It is assumed that this is a solvable task similar to [MPDCCP-paper], but is probably left to the implementer, to take care. Even if the reconstruction of the packet order does not become a standardized part of the MP-QUIC in Section 7.1.5, it possibly requires path sequencing and end-to-end sequencing. 8. QUICv1 Gap Analysis for ATSSS Phase 2 This section summarizes QUIC protocol capabilities that would be beneficial for ATSSS Phase 2, as described in Section 7.1. o ATSSS Phase 2 is focused on transport services for Ethernet frames and IP packets (with the intention of supporting TCP, UDP, and UDP-encapsulated transport protocols such as QUIC). The discussed approaches are based on tunnelling Ethernet or IP directly over QUIC. The masque working group that is currently in the chartering validation process is scoped to cover UDP and IP proxying. While UDP proxying does cover the most important use case to support ATSSS for UDP/QUIC, a more generic solution based on IP proxying would simplify the ATSSS design. However, IP proxying is only considered at a later stage by the masque working group. Also, multipath mechanisms of QUIC are not covered in the proposed charter. Boucadair, et al. Expires December 1, 2020 [Page 22] Internet-Draft QUIC ATSSS May 2020 o We envision the ability to select paths (steering), detect path failures and reroute traffic (switching), and forward packets on multiple active paths simultaneously (splitting), based on external policies, including active-standby, smallest delay, weighted load-balancing, and path selection based on assigned priorities, for the full range of encapsulated protocols in ATSSS Phase 2, similar to the abilities provided by Multipath TCP for ATSSS Phase 1. Splitting cannot be supported easily in the discussed QUICv1-based approaches. Multipath transport capability similar to Multipath TCP, as used in ATSSS Phase 1, would support splitting well. The QUIC working group is originally chartered to produce a multipath extension document by December 2021. Proposals exist, however, this work has been postponed to QUICv2 and discussion is still on-going if support will be kept in the charter. o While the base protocol for QUICv1 does not provide support for unreliable datagrams, an QUIC extension for datagram support has been adopted by the group and the QUIC working group is chartered to produce this capability by March 2021. This can be used to support for the additional user-plane protocols as envisioned in ATSSS Phase 2. o When QUIC is used as a tunneling protocol, nested congestion control mechanisms (such as QUIC encapsulated in QUIC) have implications that require further study. o When QUIC is used as a tunneling protocol, the complete ATSSS Phase 2 protocol stack would include encrypted headers at multiple layers. It needs further investigation if this is a problem for ATSSS, however, it is likely a problem that can be solved by the 3GPP. Likewise, the implications of the various encapsulation overhead is to be further assessed within 3GPP. 9. IANA Considerations This document does not make any request to IANA. 10. Security Considerations Section 9 of [RFC6459] provides an overview of security considerations in 3GPP networks. ATSSS Phase 1 data plane security considerations are documented in Section 9 of [I-D.ietf-tcpm-converters]. This document discusses the use of QUIC (including Multipath QUIC) as an additional ATSSS steering method. QUIC-specific security Boucadair, et al. Expires December 1, 2020 [Page 23] Internet-Draft QUIC ATSSS May 2020 considerations are discussed in Section 21 of [I-D.ietf-quic-transport]. This document does not specify specific mechanisms to use QUIC as a tunneling protocol towards an ATSSS proxy, as the intention of this document is to provide an informational overview of the ongoing work in 3GPP on ATSSS to support non-TCP, rather than discussing a detailed solution. Nevertheless, this document cites candidate solutions to provide such tunneling service. Security considerations specific to these solutions are provided below. Multipath QUIC-specific security considerations can be found in Section 8 of [I-D.deconinck-quic-multipath]. Section 6 of {I-D.ietf-quic-datagram} discusses security considerations specific to the use of the Unreliable Datagram Extension to QUIC. 11. Acknowledgements Many thanks to Anna Brunstrom, Dieter Gludovacz, Dirk von-Hugo, Tim Costello, Stephen Johnson, and Florin Baboescu for the review, comments, and suggestions. 12. Document History (Note to RFC Editor - if this document ever reaches you, please remove this section) Version -00: initial submission 13. References 13.1. Normative References [TS23501] 3GPP (3rd Generation Partnership Project), ., "Technical Specification Group Services and System Aspects; System Architecture for the 5G System; Stage 2 (Release 16)", 2019, . 13.2. Informative References [atsssliaison] 3GPP (3rd Generation Partnership Project), ., "LS on need for Multi-Path QUIC for ATSSS", April 2020, . Boucadair, et al. Expires December 1, 2020 [Page 24] Internet-Draft QUIC ATSSS May 2020 [Hybrid] Keukeleire, N., Hesmans, B., and O. Bonaventure, "Increasing broadband reach with Hybrid Access Networks", IEEE Communications and Standards Magazine, Vol. 4, Issue 1 , March 2020, . [I-D.amend-tsvwg-multipath-dccp] Amend, M., Bogenfeld, E., Brunstrom, A., Kassler, A., and V. Rakocevic, "DCCP Extensions for Multipath Operation with Multiple Addresses", draft-amend-tsvwg-multipath- dccp-03 (work in progress), November 2019. [I-D.bonaventure-iccrg-schedulers] Bonaventure, O., Piraux, M., Coninck, Q., Baerts, M., Paasch, C., and M. Amend, "Multipath schedulers", draft- bonaventure-iccrg-schedulers-00 (work in progress), March 2020. [I-D.boucadair-mptcp-plain-mode] Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel, D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R., Vinapamula, S., Seo, S., Cloetens, W., Meyer, U., Contreras, L., and B. Peirens, "Extensions for Network- Assisted MPTCP Deployment Models", draft-boucadair-mptcp- plain-mode-10 (work in progress), March 2017. [I-D.deconinck-quic-multipath] Coninck, Q. and O. Bonaventure, "Multipath Extensions for QUIC (MP-QUIC)", draft-deconinck-quic-multipath-04 (work in progress), March 2020. [I-D.ietf-quic-datagram] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", draft-ietf-quic-datagram-00 (work in progress), February 2020. [I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", draft-ietf-quic-transport-28 (work in progress), May 2020. [I-D.ietf-tcpm-converters] Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S., and B. Hesmans, "0-RTT TCP Convert Protocol", draft-ietf- tcpm-converters-19 (work in progress), March 2020. Boucadair, et al. Expires December 1, 2020 [Page 25] Internet-Draft QUIC ATSSS May 2020 [I-D.piraux-quic-tunnel] Piraux, M. and O. Bonaventure, "Tunneling Internet protocols inside QUIC", draft-piraux-quic-tunnel-01 (work in progress), March 2020. [I-D.piraux-quic-tunnel-tcp] Piraux, M. and O. Bonaventure, "Tunneling TCP inside QUIC", draft-piraux-quic-tunnel-tcp-00 (work in progress), March 2020. [I-D.schinazi-masque-connect-udp] Schinazi, D., "The CONNECT-UDP HTTP Method", draft- schinazi-masque-connect-udp-00 (work in progress), April 2020. [I-D.schinazi-masque-protocol] Schinazi, D., "The MASQUE Protocol", draft-schinazi- masque-protocol-01 (work in progress), March 2020. [IETFJ16] Bonaventure, O. and S. Seo, "Multipath TCP Deployment", IETF Journal, Fall 2016 , 2016, . [MPDCCP-paper] Amend, M., Bogenfeld, E., Cvjetkovic, M., Rakocevic, V., Pieska, M., Kassler, A., and A. Brunstrom, "A Framework for Multiaccess Support for Unreliable Traffic using Multipath DCCP", 2019 IEEE 44th Conference on Local Computer Networks (LCN) , 2019, . [MPQUIC-Conext] De Coninck, Q. and O. Bonaventure, "Multipath QUIC - Design and evaluation", Proceedings of the 13th international conference on emerging networking experiments and technologies 2017 Nov 28 (pp. 160-166). , 2017, . [MPTester] De Coninck, Q. and O. Bonaventure, "MultipathTester - Comparing MPTCP and MPQUIC in Mobile Environments. In 2019 Network Traffic Measurement and Analysis Conference (TMA)", 2019, . Boucadair, et al. Expires December 1, 2020 [Page 26] Internet-Draft QUIC ATSSS May 2020 [QUIC-Deployment] Kuehlewind, M., "Some updates on QUIC deployment numbers", 2019, . [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, . [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, June 2009, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, DOI 10.17487/RFC6459, January 2012, . [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, . [RFC8041] Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and Operational Experience with Multipath TCP", RFC 8041, DOI 10.17487/RFC8041, January 2017, . [RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December 2017, . [TR-348] Broadband Forum, ., "Hybrid Access Broadband Network Architecture", 2016, . Authors' Addresses Boucadair, et al. Expires December 1, 2020 [Page 27] Internet-Draft QUIC ATSSS May 2020 Mohamed Boucadair (editor) Orange Clos Courtel Rennes 35000 France Email: mohamed.boucadair@orange.com Olivier Bonaventure (editor) UCLouvain Email: Olivier.Bonaventure@uclouvain.be Maxime Piraux (editor) UCLouvain Email: Maxime.Piraux@uclouvain.be Quentin De Coninck UCLouvain Email: quentin.deconinck@uclouvain.be Spencer Dawkins (editor) Tencent America Email: spencerdawkins.ietf@gmail.com Mirja Kuehlewind (editor) Ericsson Email: mirja.kuehlewind@ericsson.com Markus Amend Deutsche Telekom Email: markus.amend@telekom.de Boucadair, et al. Expires December 1, 2020 [Page 28] Internet-Draft QUIC ATSSS May 2020 Andreas Kassler Karlstad University Email: andreas.kassler@kau.se Qing An Alibaba Group Email: anqing.aq@alibaba-inc.com Nicolas Keukeleire Tessares Email: nicolas.keukeleire@tessares.net SungHoon Seo Korea Telecom Email: sh.seo@kt.com Boucadair, et al. Expires December 1, 2020 [Page 29]