| Internet-Draft | Explicit Path-ID | November 2023 |
| Huitema | Expires 12 May 2024 | [Page] |
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.¶
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 12 May 2024.¶
Copyright (c) 2023 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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.¶
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.¶
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.¶
MP_CONNECTION_ID Frame {
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),
}
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].¶
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.¶
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.¶
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.¶
TODO. resource explosion?¶
This document registers a new value in the QUIC Transport Parameter Registry:¶
| Value | Parameter Name. | Specification |
|---|---|---|
| TBD (experiments use 0x29e3d19e) | enable_explicit_path_id | Section 2.1 |