Internet-Draft MPQUIC Alternate Path Model November 2023
Gage Expires 14 May 2024 [Page]
QUIC Working Group
Intended Status:
Standards Track
W. Gage

An Alternate Path Model for Multipath QUIC


The path model used in the current MPQUIC draft binds a connection identifier to a path. In fact, the sequence number of a connection identifier is used as an implicit path identifier. This has a number of consequences that may cause MPQUIC to diverge from the principles of RFC9000. One of these consequences, for example, is to associate each connection with a different application data packet number space rather than maintaining a single application data packet number space across all connections as defined in RFC9000.

This document proposes a different path model for Multipath QUIC using explicit path identifiers, enabling a multipath management framework that retains the principles and operations of RFC9000.

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

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 14 May 2024.

1. Introduction

Architecturally, one may consider two models for multi-path operations: model (A) is a collection of uni-path QUIC constructs while model (B) is a uni-path QUIC construct operating over a collection of paths.

Model (A) is like multipath TCP [MPTCP] and appears to be the model of the current MPQUIC design [MPQUIC-DRAFT]. Model (B) is like a TCP connection operating over a layer 2 link aggregation group [LAG]. In (B), a TCP segment can be transmitted in an IP datagram over any of the links in the LAG.

If we apply the principles of (B) to Multipath QUIC, then path management is distinct from connection management. Conceptually the Multipath QUIC stack is an [RFC9000] entity sitting on top of a path management entity with a shim entity between them to direct a QUIC packet over one of the available paths.

This document proposes a QUIC multipath model similar to (B).

In the proposed model, a QUIC packet can be sent over any of the available (and unrestricted) paths. Since connection identifiers are independent of path, a QUIC packet received over any path is processed in the same way as a packet received over the single path construct of [RFC9000] - i.e. there is a single application data packet number space and an ACK received over any path contains unambiguous packet numbers. While congestion control must clearly be path-specific, connection management, key management and packet loss recovery are not path-specific.

1.1. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.2. Terminology

This document uses the following terminology:


a collection of QUIC connections and paths used to exchange QUIC packets between two endpoints.


to be completed


to be determined

2. Multipath Management

Connection migration to a new path is already supported in [RFC9000]. A goal of multipath QUIC is to provide multiple paths that can be simultaneously active and to explicitly manage the use of paths.

Similar to [MPQUIC-DRAFT], this proposal is based on several basic design points:

  • Re-use the mechanisms of [RFC9000] as much as possible. In particular, this proposal uses path validation based on [RFC9000] and re-uses all of the connection management, key management and loss recovery procedures of [RFC9000].

  • Use the same packet header formats as [RFC9000] to avoid differences between multipath and non-multipath traffic over a particular path.

  • Do not modify frame formats defined in [RFC9000]; if necessary, define new frame types for multipath-specific operations.

Multipath QUIC requires changes to the path management mechanisms specified in Section 9 of [RFC9000]:

  • allow simultaneous transmission of non-probing frames on multiple paths;

  • continue using an existing path even if non-probing frames have been received on another path;

  • manage the removal of paths that have been abandoned or lost.

In addition, multipath QUIC may require changes to several QUIC path-specific procedures described in [RFC9002]:

  • congestion control;

  • RTT measurements;

  • PMTU discovery.

3. Path Identification

A path may be associated with the 4-tuple of an IP/UDP datagram (source IP address, destination IP address, source UDP port, and destination UDP port). However, this document explicitly assigns an identifier to each path to decouple path management from the 4-tuple of the IP/UDP datagram used to transport a QUIC packet.

A path identifier is an integer that is unique across all paths associated with a session. The initial (default) path (i.e. the path used for the exchange of QUIC initial and handshake packets) is implicitly assigned the path identifier (PathID) zero (0). New path identifiers MUST increase monotonically. A path identifier assigned to one path MUST NOT be reused as the identifier for a different path within the session.

If the 4-tuple associated with a QUIC connection changes without the use of multipath validation (Section 5.1), this is considered a passive migration event (e.g. due to a NAT rebinding) and is outside the scope of this document - i.e. it is already covered by [RFC9000].

QUIC connections exist and are managed independently of paths. An outgoing QUIC packet may be transmitted over any of the available and active paths, subject to any constraints that may have been placed on path usage by either of the QUIC endpoints (Section 6.1). Similarly, an incoming QUIC packet received over any path will be processed according to [RFC9000], as though it had been received over a uni-path transport between the QUIC endpoints.

4. High-level Overview

The multipath extensions to QUIC proposed in this document enable the simultaneous use of different paths to exchange non-probing QUIC frames. This differs from [RFC9000] where the connection migration procedure selects only one path to exchange non-probing frames.

A multipath QUIC session between peers starts with a standard QUIC handshake over an initial (default) path. As indicated by [RFC9000], an endpoint MUST NOT attempt to activate a new path before the handshake is confirmed. The peers use a new enable_multipath transport parameter during the handshake to negotiate the use of multipath capabilities. A new max_active_paths transport parameter limits the maximum number of active paths that can be used between the peers.

To add a new path to an existing multipath QUIC session, a client starts a path validation on the chosen path. A new path can only be used to transport non-probing frames once the path has been validated using mechanisms similar to those described in Section 8 of [RFC9000]. New MULTIPATH_CHALLENGE and MULTIPATH_RESPONSE frames are used to validate the path and to assign an identifier to the path. A new MULTIPATH_STATUS frame may be used to control use of a path and a new MULTIPATH_BINDING frame may be used to bind a QUIC connection identifier to a specific set of paths.

A new MULTIPATH_ABANDON frame may be used to abandon a path between peers, preventing further use of that path to exchange QUIC packets. A MULTIPATH_ABANDON frame includes the identifier assigned to the path to be abandoned, allowing the frame to be forwarded over any of the (allowable) paths active at the time of transmission.

The multipath operations described in this document do not change the basic operations described in [RFC9000]. In particular, none of the following procedures described in [RFC9000] are affected by the use of multiple paths:

  • connection management (e.g. the use of NEW_CONNECTION_ID frames and subsequent rotation of connection identifiers);

  • key management (e.g. use of key phase bit) and derivation of AEAD parameters;

  • packet loss detection and loss recovery (e.g. using type 0x02 ACK frames without ECN counts).

However, changes to [RFC9002] procedures are required to deal with path-dependent characteristics such as path MTU size, RTT and congestion. For example, a new MULTIPATH_ECN frame may be used to provide path-specific ECN information.

5. Path Activation and Removal


5.1. Path Activation

operation overview:

  • to initiate communications over a new path, an endpoint sends a MULTIPATH_CHALLENGE frame (Section 9.1) containing a new path identifier (PathID) and an unpredictable payload.

  • the frame is encapsulated (in a QUIC packet) in an IP/UDP datagram where the 4-tuple of the datagram corresponds to the new path.

  • discovery of the peer endpoint IP address and UDP port is outside the scope of this document.

  • the peer confirms used of the new path by responding with a MULTIPATH_RESPONSE frame (Section 9.2) that echoes the received PathID and payload.

  • if the initiating endpoint does not receive a confirming MULTIPATH_RESPONSE frame, it may transmit a new MULTIPATH_CHALLENGE frame using the same (or a different) IP/UDP 4-tuple but with a new PathID and a different payload.


5.2. Path Removal

operation overview:

  • to terminate communications over an established path, an endpoint sends a MULTIPATH_ABANDON frame (Section 9.5) containing the PathID of the path to be abandoned.

  • if the endpoint does not receive a MULTIPATH_ABANDON_ACK frame (Section 9.6) in response, the MULTIPATH_ABANDON frame may be retransmitted over the same or a different path.

  • the MULTIPATH_ABANDON and MULTIPATH_ABANDON_ACK frames may be transmitted over any path that is active (and allowable) at the time of transmission.


6. Path Maintenance


6.1. Path Transmission Status

operation overview:

  • an initiating endpoint may send an initiator MULTIPATH_STATUS frame (Section 9.3) to inform its peer of the desired status of a path.

  • if the peer agrees with the status change, the peer should respond with a MULTIPATH_STATUS_ACK frame (Section 9.4) that echoes the sequence number and status of the corresponding MULTIPATH_STATUS frame.

  • if the peer does not agree with the status change, the peer should respond with a new responder MULTIPATH_STATUS frame (Section 9.3) to inform the initiator of its desired status of the path. The path status sequence number in the new MULTIPATH_STATUS frame MUST be greater than the path status sequence number in the initiator MULTIPATH_STATUS frame.

  • an endpoint may also send a MULTIPATH_BINDING frame (Section 9.7) to bind a QUIC connection identifier to a specific path or set of paths.

  • the MULTIPATH_STATUS, MULTIPATH_STATUS_ACK and MULTIPATH_BINDING frames may be transmitted over any path that is active (and allowable) at the time of transmission.


6.2. Path Congestion Control

operation overview:

  • congestion control is applied per path, as described in Section 7 of [RFC9002].

  • QUIC packets sent on one path do not affect the congestion state of another path.

  • an endpoint may send a MULTIPATH_ECN frame (Section 9.8) to its peer to report ECN information received over a path.

  • an endpoint may send a MULTIPATH_MAX_DATA frame (Section 9.9) to limit the number of bytes-in-flight allowed on a path.

  • the MULTIPATH_ECN and MULTIPATH_MAX_DATA frames may be transmitted over any path that is active (and allowable) at the time of transmission.


7. Packet Scheduling

operation overview:

  • a QUIC packet may be scheduled for transmission over a given path only if:

    • the path state is not "paused" or "closed";

    • the destination connection identifier has not been bound to another path (Section 9.7);

    • transmission of the packet does not increase the number of bytes-in-flight beyond the congestion window of the path (Section 6.2)

  • if more than one path is eligible for transmission of a packet, the algorithm used to select the path is beyond the scope of this document. An implementation may, for example, use the precedence value provided in a MULTIPATH_CHALLENGE, MULTIPATH_RESPONSE or MULTIPATH_STATUS frame.

  • a precedence value is an integer that may be used to differentiate between paths when scheduling the transmission of a QUIC packet:

    • in general, a path with a higher precedence value is preferred over a path with a lower precedence value;

    • multiple paths may be assigned the same precedence value;

    • congestion control may override precedence to allow transmission over a less congested path;

    • a precedence value of zero (0) may be used to indicate that the path is in a "standby" mode and should not be selected unless no other path is available.


8. Packet Loss Detection and Recovery

operation overview:

  • QUIC senders use acknowledgements to detect lost packets and a PTO to ensure acknowledgements are received.

  • loss detection through acknowledgements is the same as described in Section 6.1 of [RFC9002].

  • loss detection through PTO requires derivation of a PTO period that accommodates the different RTT that may be experienced over different paths (Section 6.3).


9. Multipath Frame Types



     Type (i) = Type_mpChallenge,
     PathID (i),
     Initiator precedence (i),
     Data (64),



     Type (i) = Type_mpResponse,
     PathID (i),
     Responder precedence (i),
     Data (64),



     Type (i) = Type_mpStatus,
     PathID (i),
     Path Status sequence number (i),
     Path Status (i),
     [Initiator precedence (i)]



     Type (i) = Type_mpStatusAck,
     PathID (i),
     Path Status sequence number (i),
     Path Status (i),
     [Responder precedence (i)]



     Type (i) = Type_mpAbandon,
     PathID (i),
     Reason Code (i)



     Type (i) = Type_mpAbandonAck,
     PathID (i)



     Type (i) = Type_mpBinding,
     PathID (i),
     CID sequence number (i)



     Type (i) = Type_mpECN,
     PathID (i),
     ECN counts (..)



     Type (i) = Type_mpMaxData,
     PathID (i),
     Maximum data (i)


11. IANA Considerations

11.1. New QUIC transport parameters

  • enable_multipath

  • max_active_paths


11.2. New QUIC frame types

  • Type_mpChallenge

  • Type_mpResponse

  • Type_mpStatus

  • Type_mpStatusAck

  • Type_mpBinding

  • Type_mpAbandon

  • Type_mpAbandonAck

  • Type_mpECN

  • Type_mpMaxData


12. References

12.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, , <>.
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, , <>.

12.2. Informative References

Wikipedia, "Link aggregation", , <>.
Liu, Y., Ma, Y., De Coninck, Q., Bonaventure, O., Huitema, C., and M. Kühlewind, "Multipath Extension for QUIC", Work in Progress, Internet-Draft, draft-ietf-quic-multipath-06, , <>.
Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, , <>.
Pauly, T., Rosenberg, E., and D. Schinazi, "QUIC-Aware Proxying Using HTTP", Work in Progress, Internet-Draft, draft-ietf-masque-quic-proxy-00, , <>.


The authors would like to thank (manyfolks) for their input and contributions.

Author's Address

Bill Gage