idnits 2.17.1 draft-bonaventure-quic-atsss-overview-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 30, 2020) is 1424 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-amend-tsvwg-multipath-dccp-03 == Outdated reference: A later version (-02) exists of draft-bonaventure-iccrg-schedulers-00 == Outdated reference: A later version (-07) exists of draft-deconinck-quic-multipath-04 == Outdated reference: A later version (-10) exists of draft-ietf-quic-datagram-00 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-28 == Outdated reference: A later version (-03) exists of draft-piraux-quic-tunnel-01 == Outdated reference: A later version (-02) exists of draft-piraux-quic-tunnel-tcp-00 == Outdated reference: A later version (-03) exists of draft-schinazi-masque-protocol-01 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC Working Group M. Boucadair, Ed. 3 Internet-Draft Orange 4 Intended status: Informational O. Bonaventure, Ed. 5 Expires: December 1, 2020 M. Piraux, Ed. 6 Q. De Coninck 7 UCLouvain 8 S. Dawkins, Ed. 9 Tencent America 10 M. Kuehlewind, Ed. 11 Ericsson 12 M. Amend 13 Deutsche Telekom 14 A. Kassler 15 Karlstad University 16 Q. An 17 Alibaba Group 18 N. Keukeleire 19 Tessares 20 S. Seo 21 Korea Telecom 22 May 30, 2020 24 3GPP Access Traffic Steering Switching and Splitting (ATSSS) - Overview 25 for IETF Participants 26 draft-bonaventure-quic-atsss-overview-00 28 Abstract 30 This document briefly presents the Access Traffic Steering, 31 Switching, and Splitting (ATSSS) service being specified within the 32 3rd Generation Partnership Project (3GPP). The ATSSS service 33 provides network support for multihomed devices to select a path for 34 transmission (steer), move traffic from one path to another (switch), 35 or use multiple paths simultaneously (split). TS 23.501 specifies an 36 ATSSS architecture for TCP traffic. 38 This document presents a snap-shot of the ongoing discussion in the 39 3GPP to enable ATSSS for non-TCP traffic, based on the use of QUIC, 40 and assesses to what extent IETF specifications can be used to meet 41 the ATSSS design goals. Apparent gaps are also documented. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at https://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on December 1, 2020. 60 Copyright Notice 62 Copyright (c) 2020 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (https://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 1.1. Notes for Readers . . . . . . . . . . . . . . . . . . . . 4 79 2. Introduction to Access Traffic Steering, Switching, and 80 Splitting (ATSSS) . . . . . . . . . . . . . . . . . . . . . . 4 81 3. Contribution and Discussion Venues for this draft. . . . . . 5 82 4. Conventions, Terminology, and Definitions . . . . . . . . . . 6 83 5. High Level ATSSS Overview . . . . . . . . . . . . . . . . . . 7 84 5.1. Reference Architecture . . . . . . . . . . . . . . . . . 7 85 5.2. External IP Addresses Used by the ATSSS UPF . . . . . . . 8 86 5.3. ATSSS Modes . . . . . . . . . . . . . . . . . . . . . . . 9 87 5.4. ATSSS Rules . . . . . . . . . . . . . . . . . . . . . . . 9 88 6. ATSSS Phases . . . . . . . . . . . . . . . . . . . . . . . . 11 89 7. ATSSS Phase 1: Support for TCP . . . . . . . . . . . . . . . 11 90 7.1. ATSSS Phase 2: Adding Non-TCP Support . . . . . . . . . . 13 91 7.1.1. QUIC and Multihoming . . . . . . . . . . . . . . . . 14 92 7.1.2. QUIC as an ATSSS Data Plane Protocol . . . . . . . . 15 93 7.1.3. Single QUICv1 Tunnel with Unreliable Datagram 94 Extension and Connection Migration . . . . . . . . . 15 95 7.1.4. Multiple QUICv1 Tunnels with Unreliable Datagram 96 Extension and Connection Migration . . . . . . . . . 17 97 7.1.5. MP-QUIC Tunneling . . . . . . . . . . . . . . . . . . 18 98 7.2. Mapping of Both TCP and Non-TCP to QUIC Streams and 99 Datagrams . . . . . . . . . . . . . . . . . . . . . . . . 19 100 7.3. Encapsulation Overhead . . . . . . . . . . . . . . . . . 20 101 7.4. Multiple Encryptions . . . . . . . . . . . . . . . . . . 21 102 7.5. Congestion Control in Congestion Control and Coexistence 21 103 7.6. Packet Order Reconstruction for (MP-)QUIC Splitting Mode 22 104 8. QUICv1 Gap Analysis for ATSSS Phase 2 . . . . . . . . . . . . 22 105 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 106 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 107 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 108 12. Document History . . . . . . . . . . . . . . . . . . . . . . 24 109 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 110 13.1. Normative References . . . . . . . . . . . . . . . . . . 24 111 13.2. Informative References . . . . . . . . . . . . . . . . . 24 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 114 1. Introduction 116 The 3rd Generation Partnership Project (3GPP) has described the 117 Access Traffic Steering, Switching, and Splitting (ATSSS) service, 118 used to carry traffic over multiple available paths. In Release 16 119 [TS23501], ATSSS supports TCP traffic relying upon two IETF 120 protocols: MPTCP [RFC6824] and Convert Protocol 121 [I-D.ietf-tcpm-converters]. 123 As part of preparation for Release 17 studies, 3GPP has expressed an 124 interest in other IETF protocols and protocol extensions that would 125 enable ATSSS service of traffic not supported by the Convert Protocol 126 nor based on the use of MPTCP. To that aim, 3GPP has contacted the 127 IETF through a formal liaison [atsssliaison], letting the IETF know 128 about this interest. An excerpt of the liaison document is provided 129 below: 131 "The work on the study has not yet started in 3GPP, and there are 132 thus no agreed conclusions. The goal is to enable steering, 133 switching and splitting of traffic (primarily UDP) across multiple 134 accesses, including latency sensitive and real time traffic. 135 Therefore 3GPP is interested to receive regular feedback on progress 136 and prioritization on the multipath extensions to QUIC." 138 Because "3GPP SA kindly requests IETF to take the above information 139 into account when discussing future work in prioritizing the 140 multipath work for QUIC", but the complete specification of ATSSS in 141 the relevant 3GPP architecture documents reflects the complexity of 142 3GPP networks, the authors of this document worked to provide a high 143 level overview of the parts of ATSSS that would be impacted by IETF 144 protocol design, in terminology that is more familiar to IETF 145 participants. 147 1.1. Notes for Readers 149 We provide a high-level overview of ATSSS in Section 5, describe the 150 current ATSSS version in Section 7, describe our thoughts about a 151 QUIC-based version of ATSSS in Section 7.1, and conclude with our 152 understanding of the gaps between QUIC version 1 and what a QUIC- 153 based version of ATSSS will require in Section 8. 155 This document is an informational Internet-Draft from individuals, 156 and does not carry any special status within the IETF. 158 This document abstracts considerable architectural detail that is 159 available in 3GPP specifications. The goal is to make this overview 160 more accessible for IETF readers who are not familiar with 3GPP 5G 161 architecture. 163 This document makes references to Internet-Drafts that are not as 164 mature as the core QUIC Internet-Drafts, and in some cases, have not 165 been adopted as Working Group drafts yet, although all are within 166 existing and proposed IETF working group charters. The goal is to 167 give 3GPP readers the most up-to-date understanding of what is 168 possible. 170 2. Introduction to Access Traffic Steering, Switching, and Splitting 171 (ATSSS) 173 Mobile devices such as laptops, smartphones, tablets support multiple 174 network interfaces that may attach to different networks. Over the 175 years, various techniques have been proposed to support such multi- 176 interfaced devices (e.g., Shim6 [RFC5533], Mobile IPv6 [RFC6275], 177 Proxy Mobile IPv6 [RFC5213], or Multipath TCP [RFC6824]). 179 Users of these devices have different expectations concerning the 180 utilization of available network connectivity (and thus their 181 different network interfaces). For simplicity, we consider a 182 smartphone that is equipped with a Wireless LAN (WLAN) interface and 183 a cellular interface, but the discussion below can be generalized to 184 any device with multiple network interfaces that support IP. 186 Some users of these smartphones want to offload most or all of their 187 traffic onto the WLAN when the WLAN is available while expecting 188 seamless handovers when it is not available. For example, when they 189 move out of the reach of their home WLAN, they expect that the 190 established flows (e.g., TCP connections, UDP flows) will continue 191 over the cellular interface without any interruption (called "session 192 continuity" in 3GPP). As the devices are assigned different IP 193 addresses over WLAN and the cellular networks, this seamless handover 194 requires some specific assistance from the network. The current 195 utilization of Multipath TCP on Apple smartphones is an example of 196 this use case [IETFJ16]. 198 Other users want to load balance their flows over the different 199 available networks, e.g., by sending a delay-sensitive flow over 200 cellular and a long download over the WLAN network. Several 201 smartphones enable applications to indicate their preferences when 202 using available networks. This steering policy can be managed by the 203 smartphone, but flows need to continue after a handover. 205 Still other users may want to combine the resources provided by the 206 cellular and the WLAN networks to improve the up and download 207 throughput performance of individual flows. The GiGA LTE and GiGA 5G 208 services deployed using Multipath TCP in South Korea are examples of 209 this use case [IETFJ16]. 211 To support these different use cases in 5G networks, 3GPP is defining 212 the Access Traffic Steering, Switching and Splitting (ATSSS) service 213 [TS23501]. This work is further adopted by the Broadband Forum to 214 provide similar capabilities to residential gateways equipped with 215 multiple access interfaces, in the continuity of the Hybrid Access 216 Networks [TR-348]. 218 In this document, we abstract many of the technical details of future 219 5G networks to explain the capabilities ATSSS needs, which may impact 220 decisions about future work on IETF protocols. 222 3. Contribution and Discussion Venues for this draft. 224 (Note to RFC Editor - if this document ever reaches you, please 225 remove this section) 227 This document is under development in the Github repository at 228 https://github.com/obonaventure/draft-quic-atsss-reqs. Readers are 229 invited to open issues and send pull requests with contributed text 230 for this document. 232 Substantial discussion of this document should take place on the QUIC 233 working group mailing list (quic@ietf.org). Subscription and archive 234 details are at https://www.ietf.org/mailman/listinfo/quic. 236 4. Conventions, Terminology, and Definitions 238 This document makes use of 3GPP specific terms defined in [RFC6459], 239 mainly the following ones: 241 o Packet Data Network (PDN): is a packet-based network that either 242 belongs to the operator or is external (such as the Internet or a 243 corporate intranet). The user eventually accesses services in one 244 or more PDNs. The operator's packet core networks are separated 245 from packet data networks by User Plane Functions (UPFs). 247 o UE (User Equipment): refers to the devices that are hosts with the 248 ability to obtain Internet connectivity via a 3GPP network. 250 o User Plane: refers to data traffic and the required sessions for 251 the data traffic. In practice, IP is the only data traffic 252 protocol used in the user plane. 254 Also, the document uses the following additional terms: 256 o Protocol Data Unit (PDU) Session: An association between the UE 257 and the Data Network (DN) to carry the user data/traffic. 259 o PDU Connectivity Service: A service that provides exchange of PDUs 260 between an UE and a Data Network. 262 o Multi-access PDU (MA-PDU) Session: A PDU session that has 263 simultaneously user plane resources assigned on 3GPP and non-3GPP 264 access networks. 266 o User Plane Function (UPF): A logical function in the 5G core 267 network that provides the interconnect point between the mobile 268 infrastructure and the Data Network (DN) and anchor point for 269 Protocol Data Unit (PDU) Sessions to enable mobility. 271 o Data Network Name (DNN): is a Fully Qualified Domain Name (FQDN) 272 and resolves to a set of gateways in an operator's network. DNN 273 is used for the selection of the UPF(s) for a PDU Session. 275 o 5G Core (5GC) network: Refers to the part of the 5G System which 276 is independent of the access technology used by an UE (e.g., 277 cellular, WLAN) [TS23501]. A 5G Core network can be reached via 278 one or more access networks. 280 o 3GPP access network: Refers to a radio access network used by an 281 UE to reach a 5G Core network. In such case, the UE uses an 282 access technology that is specified by 3GPP. 284 o Non-3GPP access network: Refers to an access network (e.g., WLAN) 285 that is not a 3GPP access network and which is used by an UE to 286 connect to a 5G Core network. 288 o 5G control plane: Denotes the 5G control management component of 289 use plane resources (e.g., forwarding policies). 291 5. High Level ATSSS Overview 293 The 5G Core supports a service that provides exchange of data between 294 a User Equipment (UE) and a data network (referred to as Packet Data 295 Network (PDN)) identified by a Data Network Name (DNN). This 296 connectivity service, called the Protocol Data Unit (PDU) 297 Connectivity Service, is realized via 'PDU Sessions' that are 298 established upon request from User Equipment (UE) when the UE first 299 connects to that network. The type of PDU Session can be IPv4, IPv6, 300 IPv4v6, Ethernet or Unstructured. 302 It is out of the scope of this document to provide a comprehensive 303 overview of 5G System (5GS) architecture. In particular, this 304 document does not describe how PDU Sessions are established, and thus 305 how IP addresses/prefixes are assigned to requesting UEs. 307 An UE can be provided a multi-access PDU Connectivity Service. That 308 is, an UE can exchange data with a PDN by using a "3GPP access 309 network" and a "non-3GPP access network" (often a WLAN). This is 310 realized using the ATSSS service that is provided in the 5G core 311 network control plane and user plane. The user plane part of the 312 ATSSS functionality is contained in the User Plane Function (UPF) 313 that manages the UE's PDU session. 315 5.1. Reference Architecture 317 To understand the operation of the ATSSS service, it is useful to 318 consider the reference environment shown in Figure 1. An UE is 319 attached to two different access networks (Access Net A and Access 320 Net B). Each of these two networks is potentially shared with other 321 users, so the bandwidth available from each network varies over time. 322 These fluctuations in bandwidth are managed by using congestion 323 control schemes. 325 One of these access networks is managed by a 5G provider according to 326 the 3GPP specifications. The second network is potentially managed 327 by a different organization. It is important to note that in this 328 second case, there is an IPSec tunnel between the UE and a dedicated 329 device in the 5G network (not shown in Figure 1). A dedicated IP 330 address is assigned by means of Internet Key Exchange version 2 331 (IKEv2) to the UE to access the 5G Core via this second network. 333 The UE interacts with a distant server through a User Plane Function 334 hosting the ATSSS functionality. This UPF is called hereafter ATSSS 335 UPF. The ATSSS UPF enables the UE to use a transport protocol that 336 supports the different access networks even if the server does not 337 support it (i.e., does not use a multipath-capable transport 338 protocol). 340 The 5G control plane provides the UE and the ATSSS UPF with rules as 341 discussed in Section 5.4. Note that, as per 3GPP definition, the 342 rules provided to the UE are called ATSSS Rules, while the ATSSS 343 information provided to the UPF is carried via Multi-Access Rules, 344 but for simplicity this document uses the term "ATSSS rules" for the 345 ATSSS information provided to both UE and UPF. 347 ........(ATSSS Rules From Network)........ 348 . . 349 . ------------ . 350 . / \ . 351 . +-------| Access Net A |--+ . 352 . | \ (3GPP) / | . 353 . | ------------ | . 354 . | | . 355 . | | . 356 +---+--+ | +-----+ 357 | | +--------|ATSSS| +------+ 358 | UE | | |-/.../--|Server| 359 | | +--------| UPF | +------+ 360 +---+--+ | +-----+ 361 | | 362 | | 363 | ------------ | 364 | / \ | 365 +-------| Access Net B |--+ 366 \ (non 3GPP) / 367 ------------ 369 Figure 1: Simplified Reference Architecture for ATSSS 371 5.2. External IP Addresses Used by the ATSSS UPF 373 Depending on the ATSSS mode, the ATSSS UPF may translate the access 374 network specific addresses into an address called the Multi-Access 375 (MA) IP address and vice versa. Such an address is also directly 376 assigned to the UE (that is, packets that are not eligible for the 377 ATSSS service are sourced by the UE with that IP address). 379 Absent any coordination between the UE and the ATSSS UPF (e.g., 380 assignment of port ranges), the same IP address and port number could 381 be used simultaneously by the ATSSS UPF and the UE; which is 382 problematic. 384 To avoid such issue, the ATSSS UPF may be configured with a pool of 385 IP addresses that it can use in the Internet-facing interfaces 386 instead of preserving the MA IP address assigned to the UE. How that 387 pool is used is deployment- and implementation-specific. 389 5.3. ATSSS Modes 391 3GPP defines the following procedures [TS23501] that are applicable 392 between "3GPP access" and "non-3GPP access" networks: 394 o Access Traffic Steering: selection of an access network for a new 395 data flow and the transfer of the traffic of that data flow over 396 the selected access network. 398 o Access Traffic Switching: migration of all packets of an ongoing 399 data flow from one access network to another access network. Only 400 one access network is in use at a time, but this still ensures 401 session continuity. 403 o Access Traffic Splitting: forwarding the packets of a data flow 404 across multiple access networks simultaneously. 406 Techniques to provide ATSSS are classified by the 3GPP into two 407 flavors: (1) higher-layer techniques which operate above the IP layer 408 (e.g., MPTCP), and (2) lower-layer techniques which operate below the 409 IP layer. 411 5.4. ATSSS Rules 413 The 5G control plane provides the UE and the ATSSS UPF with rules 414 that specify which flows are eligible to the ATSSS service (i.e., by 415 mapping them to a Multi-Access PDU Session). Once a Multi-Access PDU 416 Session has been established, a set of rules are then delivered to 417 both the UE and the ATSSS UPF in order to enable consistent treatment 418 of the flows by both the UE and the ATSSS UPF within the Session. 420 The traffic that matches an ATSSS rule can be distributed among the 421 available access networks following one of these modes: 423 o "Active-Standby": The traffic associated with the matching flow 424 will be forwarded via a specific access (called 'active access') 425 and switched to another access (called 'standby access') when the 426 active access is unavailable. 428 o "Smallest Delay": The traffic associated with the matching flow 429 will be forwarded via the access that presents the smallest RTT. 430 To that aim, specific measurements are conducted by the UE and a 431 dedicated function co-located with the ATSSS UPF. 433 o "Load-Balancing": The traffic associated with the matching flow 434 will be distributed among the available access networks following 435 a distribution ratio (e.g., 30% via a first access, 70% via a 436 second access). 438 o "Priority-based": For this mode, accesses are assigned priority 439 levels that indicate which access to be used first. Concretely, 440 the traffic associated with the matching flow will be steered on 441 the access with a high priority till congestion is detected, then 442 the overflow will be forwarded over a low priority access. 444 In order to provide the above-mentioned steering modes, measurement 445 information about the current network state of each path is needed. 446 Often if a multipath capable protocol is used, the measurements are 447 available as part of the protocol itself. For ATSSS approaches where 448 this is not the case, a dedicated protocol called Performance 449 Measurement Function (PMF) protocol can be used. This protocol is 450 enabled between the UE and the UPF in order to provide RTT 451 measurements and report access availability/unavailability by the UE 452 to the UPF. 454 These modes of operations can be met by using multipath protocols 455 such as MPTCP [RFC6824] to select the different paths between the UE 456 and the ATSSS. Such protocols usually include two types of 457 mechanisms to control the utilization of the paths: (i) a path 458 manager and (ii) a packet scheduler [RFC8041]. The path manager 459 decides when a new subflow needs to be established over a path while 460 the packet scheduler selects the subflow over which the next packet 461 will be sent. A more detailed description of several packet 462 schedulers may be found in [I-D.bonaventure-iccrg-schedulers]. 464 The "Active-Standby" mode can be implemented using a path manager 465 that tries to use the active access and switches to the standby one 466 after a certain number of retransmissions. This mode of operation is 467 similar to the utilization of Multipath TCP on iOS smartphones 468 [RFC8041]. 470 The "Smallest Delay" mode can be implemented using a path manager 471 that establishes a subflow over both paths and a packet scheduler 472 that measures their RTTs and prefers the one having the lowest RTT. 473 These path manager and scheduler are similar to those used by 474 Multipath TCP on Linux [RFC8041]. 476 The "Load-Balancing" mode would use the same path manager with a 477 weighted round-robin scheduler. 479 The "Priority-based" mode can be implemented using a path manager 480 that is similar to the one used by the "Active-Standby" one, but 481 which reacts faster and a packet scheduler that prefers the high 482 priority path. These path manager and scheduler are similar to the 483 ones used in deployed Hybrid Access networks [Hybrid]. 485 6. ATSSS Phases 487 We first describe in Section 7 ATSSS as specified in Release 16 488 (called hereafter, ATSSS Phase 1) that uses Multipath TCP [RFC6824] 489 and the 0-RTT Convert Protocol [I-D.ietf-tcpm-converters] to handle 490 TCP traffic. We then discuss in Section 7.1 the data plane 491 requirements for Phase 2 of the ATSSS specification that 3GPP plans 492 for Release 17. More details about 3GPP releases can be found at: 493 https://www.3gpp.org/specifications/Releases. 495 7. ATSSS Phase 1: Support for TCP 497 For ATSSS with Multipath TCP functionality, a client with two 498 interfaces connected to two disjoint access networks (in this case, 499 Access Net A and Access Net B) uses MPTCP to reach an MPTCP proxy 500 over either, or both, of the access networks. This allows the client 501 to communicate with a server which does not support MPTCP. 503 During the attachment of an ATSSS-capable UE to the network, the UE 504 may retrieve the MPTCP proxy information: an IP address, a port 505 number, and the type of proxy. In the current release, the mandatory 506 MPTCP proxy type is the "Transport Converter" 507 [I-D.ietf-tcpm-converters]. 509 Also, both the MPTCP Client and MPTCP proxy are configured with ATSSS 510 rules from the network that govern how the multiple network paths 511 between the MPTCP Client and MPTCP proxy are used. This relationship 512 is shown using "." between the MPTCP Client and MPTCP Proxy in 513 Figure 2. 515 ........(ATSSS Rules From Network)........ 516 . . 517 . ------------ . 518 . / \ . 519 . +-------| Access Net A |--+ . 520 . | \ (3GPP) / | . 521 . | ------------ | . 522 . | | . 523 +------+ | +-----+ 524 |MPTCP | +--------|MPTCP| +------+ 525 | | | |=/.../==|Server| 526 |Client| +--------|Proxy| +------+ 527 +--+---+ | +-----+ 528 | | 529 | ------------ | 530 | / \ | 531 +--------| Access Net B |--+ Legend: 532 \ (non 3GPP) / --- MPTCP subflow 533 ------------ === Proxied TCP flow 535 Figure 2: Simplified Reference Architecture for ATSSS with Multipath 536 TCP 538 An ATSSS-capable UE can make use of the MPTCP functionality by 539 establishing MPTCP-assisted connections via the MPTCP proxy relying 540 upon the Convert Protocol [I-D.ietf-tcpm-converters]. The UE behaves 541 as a "Client", while the MPTCP proxy behaves as a Transport Converter 542 [I-D.ietf-tcpm-converters]. 544 The UE then sends packets bound to connections matching an ATSSS rule 545 to the provisioned Transport Converter and destination port number. 546 Concretely, the UE initiates the MPTCP connection towards the 547 Transport Converter and indicates the IP address and port number of 548 the Server within the connection establishment packet (i.e., in the 549 payload of the SYN sent to the Transport Converter). Doing so 550 enables the Transport Converter to immediately initiate a connection 551 towards that Server, without experiencing an extra delay. The 552 Transport Converter waits until the receipt of the confirmation that 553 the Server agrees to establish the connection before confirming it to 554 the Client. 556 A flow example of an MPTCP-proxied connection is shown in Figure 3. 557 This example assumes that the Server is not MPTCP-aware. The 558 instructions included in the matching ATSSS rule will be followed for 559 the management of the MPTCP connection (including the selection of 560 the access network to establish the first subflow). 562 UE MPTCP Proxy Server 563 | | | 564 |SYN, MPC [->Server:port]| SYN, MPC | 565 |----------------------->|----------------------->| 566 |<-----------------------|<-----------------------| 567 | SYN+ACK, MPC [...] | SYN+ACK | 568 |----------------------->|----------------------->| 569 | ACK, MPC | ACK | 570 | ... | ... | 572 Legend: 573 []: Convert Protocol TLVs 574 MPC: MP_CAPABLE option [RFC6824] 576 Figure 3: An Example of MPTCP-proxied Connection Matching an ATSSS 577 Rule. 579 This approach provides 0-RTT (Zero Round-Trip Time) conversion 580 service since no extra delay is induced by the Convert protocol 581 compared to connections that are not proxied. Also, the Convert 582 Protocol does not require any encapsulation (so, no tunnels). The UE 583 and the MPTCP proxy track the performance of the access networks by 584 leveraging MPTCP's internal mechanisms including congestion control 585 and round-trip-time measurements. MPTCP uses this performance 586 information to support splitting and switching. 588 If the server supports MPTCP, the Convert Protocol provides an option 589 for clients to "opt-out". In such case, an MPTCP connection is 590 directly established between the client and the server. Given that 591 few servers are MPTCP capable, relying on the ATSSS service is the 592 only option for UEs to make use of available multiple paths to most 593 servers simultaneously. 595 7.1. ATSSS Phase 2: Adding Non-TCP Support 597 The MPTCP-based ATSSS approach discussed in the previous section is 598 specific to TCP, obviously. Therefore it does not support non-TCP 599 traffic, such as UDP, QUIC [QUIC-Deployment] or IPsec and Datagram 600 Transport Layer Security (DTLS) Virtual Private Network (VPN) 601 services. 603 As the share of these protocols grows, mainly driven by QUIC 604 deployment, a future ATSSS needs to extend beyond supporting TCP 605 only. The seamless handover provided by ATSSS is particularly useful 606 for real-time traffic (e.g., voice or video calls), 608 Several proposals to carry non-TCP traffic have been discussed, 609 including using TCP [I-D.boucadair-mptcp-plain-mode] or defining 610 multipath extensions to DCCP [I-D.amend-tsvwg-multipath-dccp]. The 611 work within 3GPP now focuses on using QUIC as the baseline for ATSSS 612 Phase 2. 614 7.1.1. QUIC and Multihoming 616 For non-TCP traffic, QUIC is already the dominant part of UDP 617 traffic. A solution as realized with the Convert Protocol for 618 (MP)TCP is not possible for QUIC as a QUIC connection cannot be 619 intercepted and converted as in the ATSSS architecture for (MP)TCP 620 (Figure 2). For (MP)TCP only the transport protocol (TCP) is 621 intercepted, while transport security provided by Transport Layer 622 Security (TLS) on top of TCP stays in tact. For QUIC transport, 623 security is integrated into the transport protocol and thus cannot be 624 intercepted. 626 Some ATSSS modes can be natively supported by the base QUIC 627 specification for QUIC flows. For example, the "Active-Standby" and 628 "Smallest Delay" steering modes can be supported directly between an 629 UE and a QUIC server without any assistance from the network other 630 than the performance measurement information. 632 Further, QUIC provides a feature called connection migration 633 (Section 9 of [I-D.ietf-quic-transport]) that makes it possible to 634 move a QUIC connection from one path/IP address to another without 635 terminating and reestablishing the connection. Connection migration 636 can further enable traffic switching but does not support traffic 637 splitting as only one path can be used simultaneously. 639 An extension to QUIC to support simultaneous use of multiple paths is 640 proposed in [I-D.deconinck-quic-multipath]. However, similar to a 641 native MPTCP connection, a (MP)QUIC connection initiated between the 642 UE and a server without the ATSSS UPF assistance cannot benefit from 643 any direct application of the ATSSS steering methods based on network 644 input given that the steering policy as currently defined in ATSSS is 645 local to the UE and the ATSSS UPF and there are no means to signal 646 that policy to a remote server. 648 Network input can be especially beneficial for cases such as: 650 o avoiding unnecessary use of user quota if one of the access 651 networks is subject to volume-based quota. 653 o avoiding frequent connection migration if both access networks 654 could be used to forward packets (each with a distinct source IP 655 address). 657 7.1.2. QUIC as an ATSSS Data Plane Protocol 659 This section elaborates how non-TCP traffic (UDP or a subset like 660 QUIC) can be encapsulated into a tunnel between the UE and the ATSSS 661 UPF to enable ATSSS for all traffic, not only TCP or QUIC. This 662 section discusses to what extent QUIC can be used as a tunneling 663 protocol for the ATSSS service and whether gaps are found. 665 When tunneling non-TCP (e.g., UDP, IP) over QUIC the Unreliable 666 Datagram Extension [I-D.ietf-quic-datagram] can be used. Each data 667 packet would be transported unreliably as a datagram over a QUIC 668 connection. Transporting these datagrams unreliably as would be done 669 in IPsec or DTLS-based tunnels is especially important for flows that 670 do not require reliable delivery and would suffer from unnecessary 671 delays caused by the retransmissions used to support reliability. 672 QUIC datagrams are congestion-controlled, but since the latency 673 between the UE and the ATSSS UPF is small compared to the end-to-end 674 latency, having second, local, congestion control loops should not 675 impact the end-to-end congestion control negatively. 677 This document discusses three approaches: 679 o Use of QUIC version 1 with the Unreliable Datagram Extension 680 Section 7.1.3 682 o Use of QUIC version 1 with the Unreliable Datagram Extension but 683 with one QUIC connection over each access network Section 7.1.4 685 o Use of a single Multipath QUIC connection 686 [I-D.deconinck-quic-multipath], with the Unreliable Datagram 687 Extension, over all access networks Section 7.1.5. 689 7.1.3. Single QUICv1 Tunnel with Unreliable Datagram Extension and 690 Connection Migration 691 ------------ 692 *---------/ \---------* 693 |........| Access Net A |........| 694 |:*-------\ (3GPP) /-------*:| 695 |:| ------------ |:| 696 |v| |:| 697 +--+-+-+ +--+-+-+ 698 |QUIC | |QUIC | +------+ 699 | | | |.......>|Server| 700 |Client| |Proxy | +------+ 701 +------+ +------+ 703 ------------ 704 / \ 705 | Access Net B | Legend: 706 \ (non 3GPP) / --- QUIC tunnel connection 707 ------------ ... Tunneled non-TCP flow 709 Figure 4: Single QUICv1 tunnel 711 QUIC can be used as a tunneling protocol between the UE and the ATSSS 712 UPF. Use of the Unreliable Datagram Extension avoids unnecessary 713 delays due to local retransmissions and, more important, subsequent 714 head-of-line blocking. 716 In this case, there is (only) one QUIC connection between the UE and 717 the ATSSS UPF for a given flow. And as such, that QUIC connection 718 uses only one access network at a time. However, given the 719 connection migration capability of QUIC, the QUIC connection could be 720 moved to another access network, e.g., when the network indicates 721 that the currently used access network would go away or that its 722 capacity becomes limited. The UE can then initiate the connection 723 migration to start the path validation process as specified in 724 Section 9 of [I-D.ietf-quic-transport]. When, and how, to switch 725 over depends on the rules provided by the network (Section 5.4) and 726 the performance measurements that are accessible to both the UE and 727 the ATSSS UPF. Note that connection migration can only be at the 728 initiative of the UE as per Section 9 of [I-D.ietf-quic-transport]. 729 This means that the UPF cannot make use of a second access network 730 upon failure or degradation observed on a first access network. 732 It is thus possible to support the switching and steering functions 733 of ATSSS, but splitting cannot be supported. 735 Path validation induces a delay when switching as packets are 736 buffered. Further, congestion control state is reset on a new path 737 and needs to ramp up. When frequent handovers happen, splitting 738 traffic over multiple paths simulaneously can be beneficial for a 739 smooth user experience. Further, of course, the ability to use 740 multiple paths simultaneously also increases the maximum capacity 741 available, which can also be beneficial in some cases. 743 This option is not considered a valid approach for the ATSSS Phase 2 744 discussed within 3GPP. 746 7.1.4. Multiple QUICv1 Tunnels with Unreliable Datagram Extension and 747 Connection Migration 749 ------------ 750 *---------/ \---------* 751 |........| Access Net A |........| 752 |:*-------\ (3GPP) /-------*:| 753 |:| ------------ |:| 754 |v| |:| 755 +--+-+-+ +--+-+-+ +------+ 756 |QUIC | |QUIC |......>| | 757 | | | | |Server| 758 |Client| |Proxy |......>| | 759 +--+-+-+ +--+-+-+ +------+ 760 |^| |:| 761 |:| ------------ |:| 762 |:*-------/ \-------*:| 763 |........| Access Net B |........| Legend: 764 *---------\ (non 3GPP) /---------* --- QUIC tunnel connection 765 ------------ ... Tunneled non-TCP flow 767 Figure 5: Traffic steering of two end-to-end flows using multiple 768 QUICv1 tunnels 770 Another approach is to use one QUIC connection over each access 771 network. In this case, there are multiple QUIC connections that are 772 used as tunnels from the UE to the ATSSS UPF to transport traffic 773 that belongs to one or multiple flows. The UE and ATSSS UPF need to 774 select one QUIC connection to forward each application data packet, 775 based on the rules provided by the network. 777 This approach can support steering (by selecting just one QUIC 778 connection for each flow), switching (by moving flows from one QUIC 779 connection to another) as well as splitting when both tunnels are 780 used simultaneously for different packets of the same flow. 782 However, this approach for splitting is challenging since data from 783 the same flow are sent over different QUIC connections, again using 784 unreliable datagram to minimize head-of-line blocking. Because both 785 these QUIC connections are completely independent of each other and 786 the paths on the different access networks may have different 787 latency, this approach would likely result in reordering of packets 788 that belong to a split flow. If reordering should be avoided, this 789 would require additional signaling between the UE and the ATSSS UPF, 790 e.g., adding sequence numbers, and adding a reordering buffer and 791 logic to both the UE and ATSSS UPF. 793 Furthermore, since the bandwidth available for each QUIC connection 794 varies as a function of the congestion experienced over each access 795 network, data sent over a congested connection could delay the 796 delivery of subsequent data over another connection. 798 Experience with MPTCP on smartphones shows that its integrated 799 mechanisms (e.g., congestion control, round-trip-time estimation, 800 packet scheduler) are well suited to support splitting and switching. 801 Providing a similar service over independent QUIC connections would 802 require a complex application that would need to track the congestion 803 window, round-trip-time, and loss characteristics of the underlying 804 QUIC connections as well as some specific application layer 805 signalling to glue the various QUIC connections together. 807 7.1.5. MP-QUIC Tunneling 809 ------------ 810 *---------/ \---------* 811 | . . . .| Access Net A |. . . . | 812 |.*-------\ (3GPP) /-------*.| 813 | | ------------ | | 814 |.| |.| 815 +--+-+-+ +--+-+-+ +------+ 816 |MPQUIC| |MPQUIC| | | 817 | | | |......>|Server| 818 |Client| |Proxy | | | 819 +--+-+-+ +--+-+-+ +------+ 820 |.| |.| 821 | | ------------ | | 822 |.*-------/ \-------*.| 823 | . . . .| Access Net B |. . . . | Legend: 824 *---------\ (non 3GPP) /---------* --- MPQUIC subflow 825 ------------ ... Tunneled non-TCP flow 827 Figure 6: Traffic splitting using a Multipath QUIC tunnel 829 A third candidate solution is to leverage the ability of QUIC to 830 support multiple streams and the Unreliable Datagram Extension, and 831 to extend it with Multipath capabilities as described in 832 [I-D.deconinck-quic-multipath]. 834 In this case, there is a single (Multipath) QUIC connection between 835 the UE and the ATSSS UPF. With a multipath transport, splitting is 836 naturally supported. 838 Data sent over one access network can be retransmitted over the other 839 if the first becomes congested. Some measurements and simulations 840 have shown that Multipath QUIC provides similar performance as 841 Multipath TCP when combining different access networks 842 [MPQUIC-Conext]. 844 Steering can be also supported, similarly to MPTCP. The path 845 scheduler can map datagrams carrying an entire flow to one or another 846 access network based on the provided rules. 848 Switching can be improved by splitting traffic simultaneously over 849 both links such that the congestion window of the new path can be 850 open before the old path goes away. This makes handovers smoother. 851 Experience with Multipath TCP on smartphones has shown that handovers 852 are not a binary process. When a smartphone performs handovers, 853 there are frequently short periods of time during which both networks 854 are imperfect [MPTester]. Using use both networks simultaneously 855 during these periods, improves user experience. 857 Furthermore, traffic can be better distributed among available paths 858 based on available resources if one of the access networks fails or 859 begins to become congested. 861 7.2. Mapping of Both TCP and Non-TCP to QUIC Streams and Datagrams 863 In ATSSS Phase 1, each TCP connection originated by the UE 864 corresponds to one MPTCP connection that is terminated on the ATSSS 865 UPF. With ATSSS Phase 2 using MPQUIC as a tunneling protocol, one 866 can leverage the multi-stream capability of QUIC to carry the 867 bytestreams of multiple TCP connections over a single MPQUIC session. 869 Focusing on the case where the UE maintains one QUIC connection with 870 its ATSSS UPF, every TCP connection that it creates results in the 871 creation of a new stream of the MPQUIC connection with the ATSSS UPF. 872 Similarly the ATSSS UPF can map each incoming TCP connection from a 873 remote host onto a stream of the MPQUIC connection. This is 874 illustrated in Figure 7. Stream mapping is most beneficial for TCP, 875 as it avoids reordering and TCP anyway requires in-order delivery. 876 It is more appropriate to use QUIC with the Unreliable Datagram 877 Extension for all other traffic. 879 AAAAAA 880 ===========> +-------+ 881 // +---------|Server2| 882 || | | | 883 \/ | +-------+ 884 +------+ MPQUIC session +-----+ 885 | | <------------------------------>| | +-------+ 886 | U E | Stream1 AAAAAAAAAAAAA...AAA |ATSSS|-/.../--|Server1| 887 | | Stream2 BBBBBBBBBBBBB...BBB | UPF |<======>| | 888 | | <------------------------------>| | BBBBBB +-------+ 889 +------+ +-----+ 891 <----> MPQUIC session 892 <====> TCP connection 894 Figure 7: ATSSS Phase 2 Maps Each TCP Connection on a Stream of the 895 MPQUIC Connection Between the UE and the ATSSS UPF 897 Two application layer protocols are proposed to manage the mapping of 898 TCP connections to QUIC streams as well as the transmission of UDP 899 datagrams over QUIC datagrams: 901 (1) The proposed masque working group (wg) extends the HTTP/3 CONNECT 902 method with a UDPCONNECT method to use QUIC as a tunnel for UDP 903 traffic [I-D.schinazi-masque-connect-udp]. Another use case in scope 904 for masque wg is IP proxying which can be used for tunneling and 905 forwarding of TCP connections [I-D.schinazi-masque-protocol]. 907 (2) QUIC Tunnel is a close proposal providing similar functionalities 908 to MASQUE based on a binary protocol 909 [I-D.piraux-quic-tunnel][I-D.piraux-quic-tunnel-tcp], and focusing on 910 the ATSSS use case. 912 Both proposals rely upon single QUIC connections and inherit thus the 913 same issues discussed in Section 7.1.3 and Section 7.1.4. 915 7.3. Encapsulation Overhead 917 In 3GPP architectures, a variety of encapsulations are already used 918 to carry user data. The use of QUIC as a tunneling method for ATSSS 919 will add some additional overhead. When the user data is forwarded 920 over a non-3GPP network access, this overhead comes further in 921 addition to an IPsec tunnel between the UE to the 5G Core Network 922 which is already at least 142 octets for an IPv6 packet forwarded 923 over a non-3GPP network access. In contrast, the MPTCP based 924 mechanism in ATSSS Phase 1 does only add a minor overhead during 925 connection establishment, but no additional overhead during the rest 926 of the connection. 928 More investigation is required to assess whether the ATSSS Phase 2 929 overhead is an issue. Solutions to optimize that overhead could be 930 considered, if needed. 932 7.4. Multiple Encryptions 934 The use of QUIC as a tunneling protocol in ATSSS will add an 935 additional layer of encryption. As there is already encryptions on 936 other layers (e.g., IP Encapsulating Security Payload (ESP)) this 937 leads to multiple layers of encryption, which might be redundant. 939 Such multiple encryptions will have performance implications on the 940 UE, in particular. Means to optimize the various redundant 941 encryptions are for further investigation in 3GPP. 943 7.5. Congestion Control in Congestion Control and Coexistence 945 Many applications that are sending unreliable traffic use various 946 congestion control algorithms to detect congestion and adjust their 947 sending rate based on inferred end-to-end latency and loss 948 characteristics. Examples include Adaptive Video Streaming using 949 e.g. SCREAM [RFC8298], or other media streaming applications that 950 use QUIC as transport layer. When using QUIC version 1 with 951 Unreliable Datagram Extension or Multipath QUIC as ATSSS solution, 952 this leads to nested congestion control, where both inner and outer 953 congestion control coexist. When using Multiple QUICv1 tunnels with 954 Unreliable Datagram Extension or MP-QUIC tunneling, the packet 955 scheduler could have an additional impact on the perceived end-to-end 956 latency and loss due to the potential difference of the individual 957 path characteristics. 959 When deploying ATSSS Phase 1 and Phase 2 in parallel, with the UE 960 serving both reliable and unreliable flows, different congestion 961 control algorithms may coexist on individual paths, which may lead to 962 fairness issues or even meltdown effects. 964 We recognize that nested congestion control mechanisms (such as QUIC 965 encapsulated in QUIC or SCREAM encapsulated in QUIC) as well as the 966 coexistence of ATSSS Phase 1 and Phase 2 have implications that 967 require further study. 969 7.6. Packet Order Reconstruction for (MP-)QUIC Splitting Mode 971 Both tunnel solutions in Section 7.1.4 and Section 7.1.5 allow the 972 splitting mode for simultaneously sending data over multiple paths. 973 In this case packet reordering can occur when a QUIC tunnel 974 communication is split across paths with very different latencies. 975 Generally, applications have to deal with packet reordering, since 976 the best effort for Internet traffic has no guarantee to prevent it. 977 However, in practice, packet reordering in the network is assumed to 978 be very limited. Applications that require in-order delivery and 979 e.g. rely on TCP or implement a similar mechanism itself can be 980 sensitive to high amounts of reordering and experience decreased 981 performance. 983 As such it is desirable that the respective receiver side of the 984 tunnel termination points has the ability to reconstruct the original 985 packet ordering. While in the case when using the MPTCP converter, 986 losses are retransmitted quickly on the local segment, when the 987 Unreliable Datagram Extension for QUIC is used, the reconstruction 988 mechanism has to further account for packet loss which may occur for 989 any of the paths within the QUIC tunnel. This can cause delays in 990 the reordering logic, which in turn can have a negative impact on 991 applications that do not require in-order delivery, such as real-time 992 transmissions. 994 It is assumed that this is a solvable task similar to [MPDCCP-paper], 995 but is probably left to the implementer, to take care. Even if the 996 reconstruction of the packet order does not become a standardized 997 part of the MP-QUIC in Section 7.1.5, it possibly requires path 998 sequencing and end-to-end sequencing. 1000 8. QUICv1 Gap Analysis for ATSSS Phase 2 1002 This section summarizes QUIC protocol capabilities that would be 1003 beneficial for ATSSS Phase 2, as described in Section 7.1. 1005 o ATSSS Phase 2 is focused on transport services for Ethernet frames 1006 and IP packets (with the intention of supporting TCP, UDP, and 1007 UDP-encapsulated transport protocols such as QUIC). The discussed 1008 approaches are based on tunnelling Ethernet or IP directly over 1009 QUIC. The masque working group that is currently in the 1010 chartering validation process is scoped to cover UDP and IP 1011 proxying. While UDP proxying does cover the most important use 1012 case to support ATSSS for UDP/QUIC, a more generic solution based 1013 on IP proxying would simplify the ATSSS design. However, IP 1014 proxying is only considered at a later stage by the masque working 1015 group. Also, multipath mechanisms of QUIC are not covered in the 1016 proposed charter. 1018 o We envision the ability to select paths (steering), detect path 1019 failures and reroute traffic (switching), and forward packets on 1020 multiple active paths simultaneously (splitting), based on 1021 external policies, including active-standby, smallest delay, 1022 weighted load-balancing, and path selection based on assigned 1023 priorities, for the full range of encapsulated protocols in ATSSS 1024 Phase 2, similar to the abilities provided by Multipath TCP for 1025 ATSSS Phase 1. Splitting cannot be supported easily in the 1026 discussed QUICv1-based approaches. Multipath transport capability 1027 similar to Multipath TCP, as used in ATSSS Phase 1, would support 1028 splitting well. The QUIC working group is originally chartered to 1029 produce a multipath extension document by December 2021. 1030 Proposals exist, however, this work has been postponed to QUICv2 1031 and discussion is still on-going if support will be kept in the 1032 charter. 1034 o While the base protocol for QUICv1 does not provide support for 1035 unreliable datagrams, an QUIC extension for datagram support has 1036 been adopted by the group and the QUIC working group is chartered 1037 to produce this capability by March 2021. This can be used to 1038 support for the additional user-plane protocols as envisioned in 1039 ATSSS Phase 2. 1041 o When QUIC is used as a tunneling protocol, nested congestion 1042 control mechanisms (such as QUIC encapsulated in QUIC) have 1043 implications that require further study. 1045 o When QUIC is used as a tunneling protocol, the complete ATSSS 1046 Phase 2 protocol stack would include encrypted headers at multiple 1047 layers. It needs further investigation if this is a problem for 1048 ATSSS, however, it is likely a problem that can be solved by the 1049 3GPP. Likewise, the implications of the various encapsulation 1050 overhead is to be further assessed within 3GPP. 1052 9. IANA Considerations 1054 This document does not make any request to IANA. 1056 10. Security Considerations 1058 Section 9 of [RFC6459] provides an overview of security 1059 considerations in 3GPP networks. ATSSS Phase 1 data plane security 1060 considerations are documented in Section 9 of 1061 [I-D.ietf-tcpm-converters]. 1063 This document discusses the use of QUIC (including Multipath QUIC) as 1064 an additional ATSSS steering method. QUIC-specific security 1065 considerations are discussed in Section 21 of 1066 [I-D.ietf-quic-transport]. 1068 This document does not specify specific mechanisms to use QUIC as a 1069 tunneling protocol towards an ATSSS proxy, as the intention of this 1070 document is to provide an informational overview of the ongoing work 1071 in 3GPP on ATSSS to support non-TCP, rather than discussing a 1072 detailed solution. Nevertheless, this document cites candidate 1073 solutions to provide such tunneling service. Security considerations 1074 specific to these solutions are provided below. 1076 Multipath QUIC-specific security considerations can be found in 1077 Section 8 of [I-D.deconinck-quic-multipath]. 1079 Section 6 of {I-D.ietf-quic-datagram} discusses security 1080 considerations specific to the use of the Unreliable Datagram 1081 Extension to QUIC. 1083 11. Acknowledgements 1085 Many thanks to Anna Brunstrom, Dieter Gludovacz, Dirk von-Hugo, Tim 1086 Costello, Stephen Johnson, and Florin Baboescu for the review, 1087 comments, and suggestions. 1089 12. Document History 1091 (Note to RFC Editor - if this document ever reaches you, please 1092 remove this section) 1094 Version -00: initial submission 1096 13. References 1098 13.1. Normative References 1100 [TS23501] 3GPP (3rd Generation Partnership Project), ., "Technical 1101 Specification Group Services and System Aspects; System 1102 Architecture for the 5G System; Stage 2 (Release 16)", 1103 2019, . 1106 13.2. Informative References 1108 [atsssliaison] 1109 3GPP (3rd Generation Partnership Project), ., "LS on need 1110 for Multi-Path QUIC for ATSSS", April 2020, 1111 . 1113 [Hybrid] Keukeleire, N., Hesmans, B., and O. Bonaventure, 1114 "Increasing broadband reach with Hybrid Access Networks", 1115 IEEE Communications and Standards Magazine, Vol. 4, Issue 1116 1 , March 2020, 1117 . 1119 [I-D.amend-tsvwg-multipath-dccp] 1120 Amend, M., Bogenfeld, E., Brunstrom, A., Kassler, A., and 1121 V. Rakocevic, "DCCP Extensions for Multipath Operation 1122 with Multiple Addresses", draft-amend-tsvwg-multipath- 1123 dccp-03 (work in progress), November 2019. 1125 [I-D.bonaventure-iccrg-schedulers] 1126 Bonaventure, O., Piraux, M., Coninck, Q., Baerts, M., 1127 Paasch, C., and M. Amend, "Multipath schedulers", draft- 1128 bonaventure-iccrg-schedulers-00 (work in progress), March 1129 2020. 1131 [I-D.boucadair-mptcp-plain-mode] 1132 Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel, 1133 D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R., 1134 Vinapamula, S., Seo, S., Cloetens, W., Meyer, U., 1135 Contreras, L., and B. Peirens, "Extensions for Network- 1136 Assisted MPTCP Deployment Models", draft-boucadair-mptcp- 1137 plain-mode-10 (work in progress), March 2017. 1139 [I-D.deconinck-quic-multipath] 1140 Coninck, Q. and O. Bonaventure, "Multipath Extensions for 1141 QUIC (MP-QUIC)", draft-deconinck-quic-multipath-04 (work 1142 in progress), March 2020. 1144 [I-D.ietf-quic-datagram] 1145 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 1146 Datagram Extension to QUIC", draft-ietf-quic-datagram-00 1147 (work in progress), February 2020. 1149 [I-D.ietf-quic-transport] 1150 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1151 and Secure Transport", draft-ietf-quic-transport-28 (work 1152 in progress), May 2020. 1154 [I-D.ietf-tcpm-converters] 1155 Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S., 1156 and B. Hesmans, "0-RTT TCP Convert Protocol", draft-ietf- 1157 tcpm-converters-19 (work in progress), March 2020. 1159 [I-D.piraux-quic-tunnel] 1160 Piraux, M. and O. Bonaventure, "Tunneling Internet 1161 protocols inside QUIC", draft-piraux-quic-tunnel-01 (work 1162 in progress), March 2020. 1164 [I-D.piraux-quic-tunnel-tcp] 1165 Piraux, M. and O. Bonaventure, "Tunneling TCP inside 1166 QUIC", draft-piraux-quic-tunnel-tcp-00 (work in progress), 1167 March 2020. 1169 [I-D.schinazi-masque-connect-udp] 1170 Schinazi, D., "The CONNECT-UDP HTTP Method", draft- 1171 schinazi-masque-connect-udp-00 (work in progress), April 1172 2020. 1174 [I-D.schinazi-masque-protocol] 1175 Schinazi, D., "The MASQUE Protocol", draft-schinazi- 1176 masque-protocol-01 (work in progress), March 2020. 1178 [IETFJ16] Bonaventure, O. and S. Seo, "Multipath TCP Deployment", 1179 IETF Journal, Fall 2016 , 2016, 1180 . 1182 [MPDCCP-paper] 1183 Amend, M., Bogenfeld, E., Cvjetkovic, M., Rakocevic, V., 1184 Pieska, M., Kassler, A., and A. Brunstrom, "A Framework 1185 for Multiaccess Support for Unreliable Traffic using 1186 Multipath DCCP", 2019 IEEE 44th Conference on Local 1187 Computer Networks (LCN) , 2019, 1188 . 1190 [MPQUIC-Conext] 1191 De Coninck, Q. and O. Bonaventure, "Multipath QUIC - 1192 Design and evaluation", Proceedings of the 13th 1193 international conference on emerging networking 1194 experiments and technologies 2017 Nov 28 (pp. 160-166). , 1195 2017, . 1197 [MPTester] 1198 De Coninck, Q. and O. Bonaventure, "MultipathTester - 1199 Comparing MPTCP and MPQUIC in Mobile Environments. In 2019 1200 Network Traffic Measurement and Analysis Conference 1201 (TMA)", 2019, . 1204 [QUIC-Deployment] 1205 Kuehlewind, M., "Some updates on QUIC deployment numbers", 1206 2019, . 1209 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 1210 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 1211 RFC 5213, DOI 10.17487/RFC5213, August 2008, 1212 . 1214 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1215 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 1216 June 2009, . 1218 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1219 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1220 2011, . 1222 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 1223 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 1224 Partnership Project (3GPP) Evolved Packet System (EPS)", 1225 RFC 6459, DOI 10.17487/RFC6459, January 2012, 1226 . 1228 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1229 "TCP Extensions for Multipath Operation with Multiple 1230 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1231 . 1233 [RFC8041] Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and 1234 Operational Experience with Multipath TCP", RFC 8041, 1235 DOI 10.17487/RFC8041, January 2017, 1236 . 1238 [RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation 1239 for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December 1240 2017, . 1242 [TR-348] Broadband Forum, ., "Hybrid Access Broadband Network 1243 Architecture", 2016, 1244 . 1246 Authors' Addresses 1247 Mohamed Boucadair (editor) 1248 Orange 1249 Clos Courtel 1250 Rennes 35000 1251 France 1253 Email: mohamed.boucadair@orange.com 1255 Olivier Bonaventure (editor) 1256 UCLouvain 1258 Email: Olivier.Bonaventure@uclouvain.be 1260 Maxime Piraux (editor) 1261 UCLouvain 1263 Email: Maxime.Piraux@uclouvain.be 1265 Quentin De Coninck 1266 UCLouvain 1268 Email: quentin.deconinck@uclouvain.be 1270 Spencer Dawkins (editor) 1271 Tencent America 1273 Email: spencerdawkins.ietf@gmail.com 1275 Mirja Kuehlewind (editor) 1276 Ericsson 1278 Email: mirja.kuehlewind@ericsson.com 1280 Markus Amend 1281 Deutsche Telekom 1283 Email: markus.amend@telekom.de 1284 Andreas Kassler 1285 Karlstad University 1287 Email: andreas.kassler@kau.se 1289 Qing An 1290 Alibaba Group 1292 Email: anqing.aq@alibaba-inc.com 1294 Nicolas Keukeleire 1295 Tessares 1297 Email: nicolas.keukeleire@tessares.net 1299 SungHoon Seo 1300 Korea Telecom 1302 Email: sh.seo@kt.com