| Internet-Draft | QUIC Connection Migration | October 2020 |
| Tan, et al. | Expires 18 April 2021 | [Page] |
This document explores and classifies QUIC connection migration, and suggests possible improvements.¶
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 18 April 2021.¶
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.¶
This document explores and classifies QUIC connection migration in detail.¶
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:¶
The following abbreviations used in this document:¶
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.¶
(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)
An CM Initiator can migrate a connection to a new local address by sending packets containing non-probing frames from that address.¶
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 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) | +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ | 0x1b | +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data (64) | +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
Some situations that do not allow connection migration:¶
The section 9.1 of [QUIC-TRANSPORT] analyzes several potential security problems and solutions in the process of connection migration.¶
According to business scenarios, connection migration can be divided into multiple types, which involve different implementation technologies.¶
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.¶
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.¶
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.¶
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 [QUIC-MPQUIC]. MPCM is an event that MAY occur during MPQUIC transmission. Therefore, MPCM has more decision variables than SPCM.¶
In addition to the connection migration classification in Section 4, QUIC can also consider connection migration from strategy.¶
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.¶
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.¶
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.¶
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.¶
Except for PCM, other connection migrations can be triggered by RTT, packet loss rate, timeout, ECN or application signals.¶
TBD.¶
TBD.¶
None.¶