Private Octopus Inc.

huitema@huitema.net

Transport Internet-Draft 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.

Introduction A couple months ago, Marten Seeman proposed to revisit the use of Connection ID (CID) sequence numbers, see . 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 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.

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 when, and only when, they appear in all capitals, as shown here.

The Explicit Path ID extension

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 is not also negotiated.

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 . The changes from 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 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 ) during the handshake. The path ID of the initial connection ID is 0. If the preferred_address transport parameter is sent (see , the path ID of the supplied connection ID is 1.

MP_CONNECTION_ID frame 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 . MP_CONNECTION_ID frames are formatted as shown in .

The Path Id component is as defined in . The other compenents are as defined for the components of the NEW_CONNECTION_ID frame in .

Management of Connection IDs and Path-ID Connection identifiers are managed as specified in . The endpoints announce the number of Connection ID that they are willing to store using the active_connection_id_limit parameter defined in . 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.

Effect of RETIRE_CONNECTION_ID and MP_PATH_ABANDON frame 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 Path management generally follows the specifications of , 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.

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.

Security Considerations TODO. resource explosion?

IANA Considerations This document registers a new value in the QUIC Transport Parameter Registry: Value Parameter Name. Specification TBD (experiments use 0x29e3d19e) enable_explicit_path_id

Acknowledgements

Fastly Mozilla Mozilla sn3rd Fastly Google Alibaba Inc. Alibaba Inc. UCLouvain UCLouvain and Tessares Private Octopus Inc. Ericsson In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.