Network Working Group C. Huitema
Internet-Draft Private Octopus Inc.
Intended status: Standards Track 9 November 2023
Expires: 12 May 2024
Explicit QUIC Path-ID extension
draft-huitema-quic-mpath-explicit-00
Abstract
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 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.
Huitema Expires 12 May 2024 [Page 1]
Internet-Draft Explicit Path-ID November 2023
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3
2. The Explicit Path ID extension . . . . . . . . . . . . . . . 3
2.1. Negotiation of Explicit Path ID . . . . . . . . . . . . . 3
2.2. Path identifiers . . . . . . . . . . . . . . . . . . . . 3
2.3. MP_CONNECTION_ID frame . . . . . . . . . . . . . . . . . 4
2.4. Management of Connection IDs and Path-ID . . . . . . . . 5
2.5. Effect of RETIRE_CONNECTION_ID and MP_PATH_ABANDON
frame . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.6. Path Management . . . . . . . . . . . . . . . . . . . . . 5
3. Implementation Considerations . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
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
Huitema Expires 12 May 2024 [Page 2]
Internet-Draft Explicit Path-ID November 2023
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.
Huitema Expires 12 May 2024 [Page 3]
Internet-Draft Explicit Path-ID November 2023
* 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.
2.3. 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 [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),
}
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].
Huitema Expires 12 May 2024 [Page 4]
Internet-Draft Explicit Path-ID November 2023
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.
2.5. 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.
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?
Huitema Expires 12 May 2024 [Page 5]
Internet-Draft Explicit Path-ID November 2023
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:
+==================+=========================+===============+
| Value | Parameter Name. | Specification |
+==================+=========================+===============+
| TBD (experiments | enable_explicit_path_id | Section 2.1 |
| use 0x29e3d19e) | | |
+------------------+-------------------------+---------------+
Table 1: Addition to QUIC Transport Parameters Entries
6. Acknowledgements
7. References
7.1. Normative References
[QUIC-MP] 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,
.
[QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", RFC 9002,
.
[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, .
Huitema Expires 12 May 2024 [Page 6]
Internet-Draft Explicit Path-ID November 2023
[QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, .
7.2. Informative References
[Explicit-ID]
Seeman, M., "separate Path IDs from Connection IDs", issue
number 214, QUIC multipath Github repository , April 2023.
Author's Address
Christian Huitema
Private Octopus Inc.
Email: huitema@huitema.net
Huitema Expires 12 May 2024 [Page 7]