Explicit QUIC Path-ID extension
draft-huitema-quic-mpath-explicit-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Christian Huitema | ||
| Last updated | 2024-05-12 (Latest revision 2023-11-09) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
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.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)