Internet-Draft Explicit Path-ID November 2023
Huitema Expires 12 May 2024 [Page]
Network Working Group
Intended Status:
Standards Track
C. Huitema
Private Octopus Inc.

Explicit QUIC Path-ID extension


The work on QUIC multipath has almost converged, but we are still debating how to identify paths. The draft multipath version 06 identifies paths explicitly using the sequence number of the Connection Identifier used for sending packets on the path. The WG is considering an alternate proposal in which the path ID is explicit. In order to compare the two solutions, we propose here an extension to the multipath draft allowing endpoints to negotiate the use of explicit sequence numbers. When the extension is negotiated, endpoints announce new connection identifiers using a new MP_CONNECTION_ID frame, which carries the parameters of the NEW_CONNECTION_ID plus a path ID. This path ID is used instead of the CID sequence number to identify packet number spaces, to create encryption nonces, to identify paths in MP_ACK, MP_ABANDON, MP_AVAILABLE and MP_STANBY frames, and to perform the logic associated with path creation, path CID rotation, and NAT rebinding. The draft analyzes the pros and cons of using this extension. After experimentation and analysis, we expect that this extension will be either absorbed into a new version of the QUIc multipath draft, or abandoned.

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

Table of Contents

1. Introduction

A couple months ago, Marten Seeman proposed to revisit the use of Connection ID (CID) sequence numbers, see [Explicit-ID]. Marten's argument was that using explicit path identifiers would simplify path management, path initiation and loss recovery. The reaction to that proposal was mixed. On one hand, the solution proposed in draft-06 of [QUIC-MP] is already implemented in multiple interoperable implementations, and covers the required QUIC Multipath scenarios. On the other hand, the usage of CID sequence numbers as identifiers of packet number spaces interferes with loss recovery after CID rotation. This can be alleviated by special code linking old and new number spaces, but there is still a hard to cover special case when CID rotation and NAT rebinding happen simultaneously. In addition, having explicit path identifiers would allow endpoints to control the number of paths independently of the number of connection identifiers.

This document proposes a QUIC extension that would allow testing and evaluation of the explicit path identifier proposal.

1.1. Conventions and Definitions

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.

2. The Explicit Path ID extension

2.1. Negotiation of Explicit Path ID

The path management extension is negotiated by means of the "enable_explicit_path_id" transport parameter:

  • "enable_explicit_path_id" (current version uses 0xced74c7a, the first 32 bits of the MD5 hash of the string "Marten might be right after all"). This parameter has a zero-length value.

If any of the endpoints does not advertise the enable_explicit_path_id transport parameter, then the endpoints MUST NOT use any frame or mechanism defined in this document.

The enable_explicit_path_id parameter MUST NOT be presented if the enable_multipath parameter defined in [QUIC-MP] is not also negotiated.

2.2. Path identifiers

The Explicit QUIC Path-ID extension defines a "Path ID" as an integer between 0 and 2^62 - 1. The Path-ID is used instead of the destination Connection ID sequence number in all places where the destination Connection ID sequence number identifies a path in [QUIC-MP]. The changes from [QUIC-MP] are:

  • Each CID is associated with a Path-ID, as documented in {#mp-connection-id-frame}. Multiple connection identifiers can be associated with the same path-id.

  • Each endpoint associates a Receiver Packet Number space to each Path ID that it provides to the peer.

  • Each endpoint associates a Sender Packet Number space to each Path-ID received from the peer.

  • The path ID associated with the Destination Connection ID is used to construct the packet protection nonce defined in Section 5.2 of [QUIC-MP]

  • The path ID associated with the Destination Connection ID is used to identify the path in ACK_MP frames.

  • The path ID associated with the Destination Connection ID used by the peer is used to identify the path in the PATH_ABANDON, PATH_STANDBY and PATH_AVAILABLE frames.

The initial connection ID issued by an endpoint is sent in the Source Connection ID field of the long packet header (see Section 17.2 of [QUIC-TRANSPORT]) during the handshake. The path ID of the initial connection ID is 0. If the preferred_address transport parameter is sent (see Section 9.6 of [QUIC-TRANSPORT], the path ID of the supplied connection ID is 1.


When the enable_explicit_path_id option is negotiated, endpoints use the MP_CONNECTION_ID frame in lieu of the NEW_CONNECTION_ID frame defined in [QUIC-TRANSPORT].

MP_CONNECTION_ID frames are formatted as shown in Figure 1.

  Type (i) = TBD (current version uses 0x15228c09),
  Sequence Number (i),
  Retire Prior To (i),
  Path Id (i),
  Length (8),
  Connection ID (8..160),
  Stateless Reset Token (128),
Figure 1: MP_CONNECTION_ID Frame Format

The Path Id component is as defined in Section 2.2. The other compenents are as defined for the components of the NEW_CONNECTION_ID frame in Section 19.15 of [QUIC-TRANSPORT].

2.4. Management of Connection IDs and Path-ID

Connection identifiers are managed as specified in [QUIC-TRANSPORT]. The endpoints announce the number of Connection ID that they are willing to store using the active_connection_id_limit parameter defined in Section 18.2 of [QUIC-TRANSPORT]. Endpoints use the RETIRE_CONNECTION_ID frame to signal that they won't use a Connection ID any more. They use the Retire Prior To parameter of MP_CONNECTION_ID Frames to induce the peer to retire obsolete Connection identifiers.


Receiving a RETIRE_CONNECTION_ID frame DOES NOT cause an endpoint to discard the resources associated with the Path-ID associated with the Connection Identifier. These resources are only discarded after an explicit PATH_ABANDON, or at the end of the connection.

2.6. Path Management

Path management generally follows the specifications of Section 4 of [QUIC-MP], but with a series of modifications:

  • To open a new path, the client SHALL use different Connection IDs on different paths, selecting for each path Connection IDs for which the path ID is not yet in use.

  • When responding on a path, the server SHOULD use a connection ID for which the path ID is not yet in use. There is no requirement that the server and the client use matching path-ID.

The endpoints retain the sending IP addresses and UDP ports associated with the path (4 tuple), as well as the sending and receiving connection IDs used.

  • if the 4 tuple are different but the path-ID is the same, the packet arrival is treated as a NAT rebinding for the specified path.

  • if CID are different but path-ID are the same, the packet arrival is treated as a CID renewal for the specified path.

3. Implementation Considerations

Retiring path-id? Does Abandon(path-ID) removes all the connection ID with that path?

If "Abandon Path", how can the endpoint ensure that there are no future references to the same path?

Maintaining the packet sequence number across multiple CID -- especially if multiple interfaces.

4. Security Considerations

TODO. resource explosion?

5. IANA Considerations

This document registers a new value in the QUIC Transport Parameter Registry:

Table 1: Addition to QUIC Transport Parameters Entries
Value Parameter Name. Specification
TBD (experiments use 0x29e3d19e) enable_explicit_path_id Section 2.1

6. Acknowledgements

7. References

7.1. Normative References

Liu, Y., Ed., Ma, Y., De Coninck, Q., Ed., Bonaventure, O., Huitema, C., and M. Kuehlewind, Ed., "Multipath Extension for QUIC", Work in Progress, Internet-Draft, draft-ietf-quic-multipath, <>.
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, <>.
Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, <>.
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, <>.
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, , <>.

7.2. Informative References

Seeman, M., "separate Path IDs from Connection IDs", issue number 214, QUIC multipath Github repository , .

Author's Address

Christian Huitema
Private Octopus Inc.