QUIC WG L. Tan
Internet-Draft Beijing Jiaotong University
Intended status: Informational X. Gao
Expires: April 18, 2021 China Unicom
W. Su
Beijing Jiaotong University
N. Li
CNCERT/SD
W. Zhang
Shandong Computing Science Center
October 15, 2020
Connection Migration in QUIC
draft-tan-quic-connection-migration-00
Abstract
This document explores and classifies QUIC connection migration, and
suggests possible improvements.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2021.
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
Tan, et al. Expires April 18, 2021 [Page 1]
Internet-Draft QUIC Connection Migration October 2020
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
3. Connection Migration . . . . . . . . . . . . . . . . . . . . 4
3.1. Initiating Connection Migration . . . . . . . . . . . . . 5
3.2. Path Verification . . . . . . . . . . . . . . . . . . . . 5
3.3. Completing Connection Migration . . . . . . . . . . . . . 6
3.4. Special Cases . . . . . . . . . . . . . . . . . . . . . . 7
4. Classification of Connection Migration . . . . . . . . . . . 7
4.1. Active Connection Migration and Passive Connection
Migration . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Vertical Connection Migration and Horizontal Connection
Migration . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Client Connection Migration and Server Connection
Migration . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Single-path Connection Migration and Multi-path
Connection Migration . . . . . . . . . . . . . . . . . . 8
5. Connection Migration Strategy . . . . . . . . . . . . . . . . 9
5.1. Failover Mode . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Standby Mode . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Aggregation Mode . . . . . . . . . . . . . . . . . . . . 9
5.4. Load Balance Mode . . . . . . . . . . . . . . . . . . . . 9
6. Trigger Condition for Connection Migration . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. Normative references . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
This document explores and classifies QUIC connection migration in
detail.
2. Terminology
Tan, et al. Expires April 18, 2021 [Page 2]
Internet-Draft QUIC Connection Migration October 2020
2.1. Terms Used In This Document
This document uses the terminology and concepts established in
[QUIC-TRANSPORT]. It is assumed that the reader is familiar with the
above document and the terms defines there.
The following terms used in this document:
Endpoint An entity that can participate in a QUIC connection by
generating, receiving, and processing QUIC packets.
There are only two types of endpoint in QUIC: client
and server.
QUIC Client The endpoint that initiates a QUIC connection.
QUIC Server The endpoint that accepts a QUIC connection.
Connection ID An identifier that is used to identify a QUIC
connection at an endpoint. Each endpoint selects one
or more Connection IDs for its peer to include in
packets sent towards the endpoint. This value is
opaque to the peer.
Connection migration The QUIC endpoint uses the connection ID to
make connections to survive changes to endpoint
addresses.
Connection migration initiator The endpoint that initiated the
connection migration.
Connection migration responder The peer communicating with the
connection migration initiator.
Path validation Endpoints test reachability between a specific local
address and a specific peer address.
Probing frame A Frame with probing function, such as PATH_CHALLENGE,
PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frame.
Non-probing frame A frame except the probing frame.
Probing packet A packet containing only probing frame.
Non-probing packet A packet containing any other non-probing frame.
Application An entity that uses QUIC to send and receive data.
2.2. Abbreviations
The following abbreviations used in this document:
CM Connection Migration.
ACM Active Connection Migration.
PCM Passive Connection Migration.
VCM Vertical Connection Migration.
HCM Horizontal Connection Migration.
CCM Client Connection Migration.
SCM Server Connection Migration.
SPCM Single-path Connection Migration.
MPCM Multi-path Connection Migration.
Tan, et al. Expires April 18, 2021 [Page 3]
Internet-Draft QUIC Connection Migration October 2020
3. Connection Migration
QUIC connections are not strictly bound to a single network path.
Connection migration is one of the important features of QUIC.
The QUIC endpoint that initiates the connection migration is called
the connection migration initiator (CM Initiator). The peer is the
connection migration responder (CM Responder).
Connection migration uses connection ID to allow connections to
transfer to a new network path. The use of a connection ID allows
connections to survive changes to endpoint addresses (IP address and
port), such as those caused by an endpoint migrating to a new
network, as shown in Figure Figure 1.
The connection ID MUST be non-zero.
Tan, et al. Expires April 18, 2021 [Page 4]
Internet-Draft QUIC Connection Migration October 2020
(Before connection migration)
+--------------+ Non-probing Packet +--------------+
| CM Initiator | -------------------> | |
|(Source IP: 1)| <------------------- | |
+--------------+ Non-probing Packet | |
| | |
| | |
| | |
v Probing Packet | |
+--------------+ (PATH_CHALLENGE) | |
| | -------------------> | |
| | <------------------- | |
| | Probing Packet | |
| | (PATH_RESPONSE) | |
| | | CM Responder |
| | Probing Packet | |
| | (PATH_CHALLENGE) | |
| CM Initiator | <------------------- | |
|(Source IP: 2)| -------------------> | |
| | Probing Packet | |
| | (PATH_RESPONSE) | |
| | | |
| | Non-probing Packet | |
| | -------------------> | |
| | <------------------- | |
| | Non-probing Packet | |
+--------------+ +--------------+
(After connection migration)
Figure 1: The connection migration
3.1. Initiating Connection Migration
An CM Initiator can migrate a connection to a new local address by
sending packets containing non-probing frames from that address.
3.2. Path Verification
The endpoint sends a PATH_CHALLENGE frame containing a random number
to initialize path verification. Each endpoint validates its peer's
address during connection establishment. Therefore, a migrating
endpoint can send to its peer knowing that the peer is willing to
receive at the peer's current address.
Path verification MUST be performed for most connection migrations,
unless the endpoints have verified the path, the reason is to verify
the reachability and security of the path. But in some special
Tan, et al. Expires April 18, 2021 [Page 5]
Internet-Draft QUIC Connection Migration October 2020
cases, the connection migration initiator should be allowed to send
data packets directly without path confirmation from the peer. The
condition is to ensure that the packet received by connection
migration responder does not carry a spoofed source address.
Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check
reachability to the peer and for path validation during connection
migration.
PATH_CHALLENGE frames are formatted as shown in Figure Figure 2.
A PATH_RESPONSE frame (type=0x1b) is sent in response to a
PATH_CHALLENGE frame.
PATH_RESPONSE frames are formatted as shown in Figure Figure 3.
+-+-+-+-+-+-+-+-+
| 0x1a |
+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data (64) |
+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PATH_CHALLENGE Frame Format
+-+-+-+-+-+-+-+-+
| 0x1b |
+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data (64) |
+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PATH_RESPONSE Frame Format
3.3. Completing Connection Migration
The endpoint receives a packet containing the new peer address of the
non-probing frame from the peer, indicating that the connection
migration initiator has migrated to this address.
After the connection is migrated, the endpoints need to reset the
congestion control parameters.
Tan, et al. Expires April 18, 2021 [Page 6]
Internet-Draft QUIC Connection Migration October 2020
3.4. Special Cases
Some situations that do not allow connection migration:
1. An endpoint MUST NOT initiate connection migration before the
handshake is confirmed, as defined in section 4.1.2 of
[QUIC-TLS].
2. An endpoint MUST NOT initiate connection migration if the peer
sent the disable_active_migration transport parameter.
The section 9.1 of [QUIC-TRANSPORT] analyzes several potential
security problems and solutions in the process of connection
migration.
4. Classification of Connection Migration
According to business scenarios, connection migration can be divided
into multiple types, which involve different implementation
technologies.
4.1. Active Connection Migration and Passive Connection Migration
According to different initiators, connection migration can be
divided into Active Connection Migration (ACM) and Passive Connection
Migration (PCM).
From the perspective of the network model, ACM can be regarded as
connection migration initiated by the application layer, and PCM can
be regarded as connection migration initiated by the IP layer or
lower layers.
ACM requires the IP layer to present all available network
connections to QUIC. The application layer or QUIC designs an
effective connection migration strategy according to the measurement
results of different network connections to achieve better user
experience, security and economy. Available migration strategies
include threshold-driven migration, polling migration, random
migration, etc.
The purpose of PCM is to maintain the connection between the QUIC
client and the QUIC server in a mobile or weak network environment.
QUIC is often forced to adapt to PCM. In addition, NAT/NAPT will
also cause QUIC endpoints to perform forced connection migration.
Tan, et al. Expires April 18, 2021 [Page 7]
Internet-Draft QUIC Connection Migration October 2020
4.2. Vertical Connection Migration and Horizontal Connection Migration
Due to the movement of QUIC terminals or access networks, QUIC needs
to support connection migration in a multi-network access
environment. Therefore, connection migration in this situation can
be divided into Vertical Connection Migration (VCM) and Horizontal
Connection Migration (HCM).
VCM occurs between heterogeneous networks and HCM occurs in
homogeneous networks. Due to temporal and spatial changes, VCM and
HCM MAY occur alternately or simultaneously. Since the HCM occurs
under a homogeneous network, the network before migration MAY have
some similarities with the network after migration. This guides QUIC
to better maintain connections by drawing on historical information.
4.3. Client Connection Migration and Server Connection Migration
In most cases, the QUIC server is stationary. QUIC connection
migration occurs on the QUIC client side. However, in scenarios such
as P2P networks, mobile servers, and data center four-layer load
balancing, both endpoints of QUIC communication MAY undergo
connection migration.
According to the location, connection migration is divided into
Client Connection Migration (CCM) and Server Connection Migration
(SCM).
The section 9 of [QUIC-TRANSPORT] stipulates that only QUIC clients
can actively initiate connection migration. The client MUST discard
packets from unknown servers. The section 9.6 of [QUIC-TRANSPORT]
describes the scene when clients initially connect to an address
shared by multiple servers but would prefer to use a unicast address
to ensure connection stability. So we believe that the client and
server should be equal, and SCM is necessary.
4.4. Single-path Connection Migration and Multi-path Connection
Migration
According to the number of connection paths maintained between the
client and the server during connection migration, connection
migration can be divided into single-path connection migration (SPCM)
and multi-path connection migration (MPCM).
SPCM is a simple and common form of connection migration. However,
in the future, with the continuous development of heterogeneous
converged networks, it is also possible for endpoints to perform
connection migration while maintaining multi-path transmission. It
is worth noting that there is a difference between MPCM and MPQUIC
Tan, et al. Expires April 18, 2021 [Page 8]
Internet-Draft QUIC Connection Migration October 2020
[QUIC-MPQUIC]. MPCM is an event that MAY occur during MPQUIC
transmission. Therefore, MPCM has more decision variables than SPCM.
5. Connection Migration Strategy
In addition to the connection migration classification in Section 4,
QUIC can also consider connection migration from strategy.
5.1. Failover Mode
In failover mode, the networking stack monitors the quality of the
connection or link, when they are not operating normally, the QUIC
connection is migrated to an alternative path.
QUIC doesn't require any packets to be exchanged before migrating to
a new path, so this migration is seamless. However, if the new path
hasn't been validated, there's less confidence that it will work. In
this mode, the QUIC connection MAY be temporarily interrupted.
5.2. Standby Mode
In standby mode, the networking stack establishes and validates an
alternative path shortly after establishing a connection on the main
path. When the link or the connection deteriorate, QUIC can switch
to the alternative path.
This means that there are two or more logical paths between the QUIC
client and the QUIC server. In this mode, QUIC always uses only one
of these paths for communication at any time.
5.3. Aggregation Mode
In the aggregation mode, the QUIC client (or QUIC server) can use
MPQUIC [QUIC-MPQUIC] technology to achieve greater network
throughput. This means that multiple source IPs will share the same
connection ID.
5.4. Load Balance Mode
The section 9.6 of [QUIC-TRANSPORT] detailed load balancing mode.
Servers MAY communicate a preferred address of two or more addresses
to allow clients to pick the one most suited to their network
attachment. The client SHOULD select one of the two or more
addresses provided by the server and initiate path validation. As
soon as path validation succeeds, the client SHOULD begin sending all
future packets to the new server address using the new connection ID
and discontinue use of the old server address.
Tan, et al. Expires April 18, 2021 [Page 9]
Internet-Draft QUIC Connection Migration October 2020
6. Trigger Condition for Connection Migration
Except for PCM, other connection migrations can be triggered by RTT,
packet loss rate, timeout, ECN or application signals.
7. Security Considerations
TBD.
8. IANA Considerations
TBD.
9. Acknowledgements
None.
10. Normative references
[QUIC-MPQUIC]
Coninck, Q. and O. Bonaventure, "Multipath Extensions for
QUIC (MP-QUIC)", August 2020,
<https://tools.ietf.org/html/draft-deconinck-quic-
multipath-05>.
[QUIC-TLS]
Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
September 2020,
<https://tools.ietf.org/html/draft-ietf-quic-tls-31>.
[QUIC-TRANSPORT]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", September 2020,
<https://tools.ietf.org/html/draft-ietf-quic-transport-
31>.
Authors' Addresses
Lizhuang Tan
Beijing Jiaotong University
Shangyuan Cun. 3.
Haidian, Beijing 100044
China
Email: lzhtan@bjtu.edu.cn
Tan, et al. Expires April 18, 2021 [Page 10]
Internet-Draft QUIC Connection Migration October 2020
Xiaochuan Gao
China Unicom
Zhonghe Street. 1.
Daxing, Beijing 100176
China
Email: gaoxc50@chinaunicom.cn
Wei Su
Beijing Jiaotong University
Shangyuan Cun. 3.
Haidian, Beijing 100044
China
Email: wsu@bjtu.edu.cn
Na Li
CNCERT/SD
Jingshiyi Road. 40.
Shizhong, Jinan 250002
China
Email: lina@cert.org.cn
Wei Zhang
Shandong Computing Science Center
Keyuan Road. 19.
Lixia, Jinan 250014
China
Email: wzhang@qlu.edu.cn
Tan, et al. Expires April 18, 2021 [Page 11]