Connection Migration in QUIC

This document explores and classifies QUIC connection migration in detail.

This document uses the terminology and concepts established in . It is assumed that the reader is familiar with the above document and the terms defines there. The following terms used in this document: 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. The endpoint that initiates a QUIC connection. The endpoint that accepts a QUIC connection. 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. The QUIC endpoint uses the connection ID to make connections to survive changes to endpoint addresses. The endpoint that initiated the connection migration. The peer communicating with the connection migration initiator. Endpoints test reachability between a specific local address and a specific peer address. A Frame with probing function, such as PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frame. A frame except the probing frame. A packet containing only probing frame. A packet containing any other non-probing frame. An entity that uses QUIC to send and receive data.

The following abbreviations used in this document: Connection Migration. Active Connection Migration. Passive Connection Migration. Vertical Connection Migration. Horizontal Connection Migration. Client Connection Migration. Server Connection Migration. Single-path Connection Migration. Multi-path 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 . The connection ID MUST be non-zero.

| | |(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 . A PATH_RESPONSE frame (type=0x1b) is sent in response to a PATH_CHALLENGE frame. PATH_RESPONSE frames are formatted as shown in Figure .

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: An endpoint MUST NOT initiate connection migration before the handshake is confirmed, as defined in section 4.1.2 of . An endpoint MUST NOT initiate connection migration if the peer sent the disable_active_migration transport parameter. The section 9.1 of 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 stipulates that only QUIC clients can actively initiate connection migration. The client MUST discard packets from unknown servers. The section 9.6 of 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 . 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 , 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 technology to achieve greater network throughput. This means that multiple source IPs will share the same connection ID.

The section 9.6 of 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.

None.