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