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