change MP-QUIC to QUIC-MULTIPATH

Author: t-aus-m

draft-tjohn-quic-multipath-dmtp.md

@@ -1,5 +1,5 @@
 ---
-title: "Deadline Aware Streams in MP-QUIC"
+title: "Deadline Aware Streams in QUIC Multipath"
 category: info # TODO: Figure out correct category
 
 docname: draft-tjohn-quic-multipath-dmtp-latest
@@ -32,7 +32,7 @@ author:
 normative:
    QUIC: rfc9000
    QUIC-TLS: rfc9001
-   MP-QUIC: I-D.draft-ietf-quic-multipath
+   QUIC-MULTIPATH: I-D.draft-ietf-quic-multipath
    QUIC-AFEC: I-D.draft-dmoskvitin-quic-adaptive-fec
    RFC3339:
    RFC9473:
@@ -46,23 +46,23 @@ informative:
 
 --- abstract
 
-This document proposes the Deadline-aware Multipath Transport Protocol (DMTP) concept as an extension to the Multipath Extension for QUIC (MP-QUIC). This extension aims to support data streams with strict latency requirements by enabling the signaling of a stream's deadline and by combining multipath scheduling, congestion control adaptations, and optional forward error correction (FEC). Moreover, DMTP leverages MP-QUIC's path identifiers to distinguish different end-to-end paths as they may be offered in a Path Aware Network (PAN) such as SCION. This allows an application to select its preferred paths while maintaining interoperability with standard MP-QUIC endpoints. In combination, DMTP enables endpoints to exchange and schedule deadline-aware streams across multiple network paths.
+This document proposes the Deadline-aware Multipath Transport Protocol (DMTP) concept as an extension to the Multipath Extension for QUIC (QUIC-MULTIPATH). This extension aims to support data streams with strict latency requirements by enabling the signaling of a stream's deadline and by combining multipath scheduling, congestion control adaptations, and optional forward error correction (FEC). Moreover, DMTP leverages QUIC-MULTIPATH's path identifiers to distinguish different end-to-end paths as they may be offered in a Path Aware Network (PAN) such as SCION. This allows an application to select its preferred paths while maintaining interoperability with standard QUIC-MULTIPATH endpoints. In combination, DMTP enables endpoints to exchange and schedule deadline-aware streams across multiple network paths.
 
 --- middle
 
 # Introduction
 
-The Multipath Extension for QUIC {{MP-QUIC}} enhances performance by simultaneously utilizing multiple paths between endpoints. However, MP-QUIC currently lacks support for strict deadline requirements of real-time applications such as teleoperation, live video streaming, or interactive gaming, which are becoming increasingly important. These applications demand low and bounded latency, and can often tolerate no or only partial retransmission of missing data.
+The Multipath Extension for QUIC {{QUIC-MULTIPATH}} enhances performance by simultaneously utilizing multiple paths between endpoints. However, QUIC-MULTIPATH currently lacks support for strict deadline requirements of real-time applications such as teleoperation, live video streaming, or interactive gaming, which are becoming increasingly important. These applications demand low and bounded latency, and can often tolerate no or only partial retransmission of missing data.
 
 Previous work on deadline-aware protocols for QUIC includes the Deadline-aware Transport Protocol {{QUIC-DTP}}, a single-path approach that introduced deadlines for streams but did not exploit multipath capabilities. Meanwhile, our DMTP {{DMTP}} approach allows to take advantage of multiple paths, combined with forward error correction (FEC) and intelligent retransmissions, to significantly increase the fraction of packets meeting their deadlines, especially in the presense of lossy or high-latency links.
 
-By integrating deadline-aware concepts into MP-QUIC, we seek to enable:
+By integrating deadline-aware concepts into QUIC-MULTIPATH, we seek to enable:
 
 1. Multipath streams with Deadlines: Scheduling and transmitting data across multiple paths, with strict deadlines of streams driving scheduling decisions.
-2. Option for Path-Aware Networking: Support for path selection as offered in Path Aware Networks (e.g., {{SCION}}) by mapping each potential path to an MP-QUIC path identifier.
+2. Option for Path-Aware Networking: Support for path selection as offered in Path Aware Networks (e.g., {{SCION}}) by mapping each potential path to an QUIC-MULTIPATH path identifier.
 3. Deadline-Based Retransmission / FEC: Combining optional adaptive FEC (such as {{QUIC-AFEC}}) and "smart" retransmissions only when there may still be time left to meet the deadline.
 
-This draft specifies a minimal set of protocol extensions for MP-QUIC to exchange deadline information at the transport layer, so that endpoints can coordinate scheduling for multipath transmissions with strict time constraints. As the first version of our proposal, our goal is to gather community feedback and gauge interest to guide future refinements.
+This draft specifies a minimal set of protocol extensions for QUIC-MULTIPATH to exchange deadline information at the transport layer, so that endpoints can coordinate scheduling for multipath transmissions with strict time constraints. As the first version of our proposal, our goal is to gather community feedback and gauge interest to guide future refinements.
 
 ## Motivation and Applications
 
@@ -79,13 +79,13 @@ Real-time applications often produce data blocks (e.g., video frames or control
 
 Within this document:
 - "Deadline-aware streams" refers to streams in which an application indicates a time by which data must be delivered, beyond which data is no longer useful.
-- "Path" aligns with the MP-QUIC concept: each path is identified by a unique Path ID and it may reference a specific combination of source and destination IP:port tuples or multiple paths as they may be offered in a path aware network, as defined by {{RFC9473}}.
+- "Path" aligns with the QUIC-MULTIPATH concept: each path is identified by a unique Path ID and it may reference a specific combination of source and destination IP:port tuples or multiple paths as they may be offered in a path aware network, as defined by {{RFC9473}}.
 
 # Design Overview
 
-## Integrating Deadline-Aware Streams into MP-QUIC
+## Integrating Deadline-Aware Streams into QUIC-MULTIPATH
 
-Our design goal is to extend MP-QUIC with minimal changes. The proposed extension enables endpoints to signal a stream's deadline. Implementations that support deadline-aware streams MUST implement:
+Our design goal is to extend QUIC-MULTIPATH with minimal changes. The proposed extension enables endpoints to signal a stream's deadline. Implementations that support deadline-aware streams MUST implement:
 
 1. Path Selection: Select paths for transmitting frames, retransmissions and acknowledgements based on metrics relevant to meeting deadlines, including:
    - Path latency measurements
@@ -112,20 +112,20 @@ Our design goal is to extend MP-QUIC with minimal changes. The proposed extensio
    - Signal deadline misses to the application layer
    - Allow applications to specify handling of missed deadlines
 
-### Extensions to MP-QUIC
+### Extensions to QUIC-MULTIPATH
 
-Our extensions build on {{MP-QUIC}}'s multipath framework (e.g., paths, path IDs, and validation) and add only:
+Our extensions build on {{QUIC-MULTIPATH}}'s multipath framework (e.g., paths, path IDs, and validation) and add only:
 
 - A transport parameter to enable deadline-aware streams.
 - A DEADLINE_CONTROL frame to signal stream deadlines.
 - An optional DMTP_ACK frame for improved per-path delay feedback.
 - Optional AFEC support via an extra transport parameter and two frames for source and repair symbol metadata.
 
-This preserves the original wire format, ensuring interoperability with {{MP-QUIC}} endpoints that do not implement these extensions.
+This preserves the original wire format, ensuring interoperability with {{QUIC-MULTIPATH}} endpoints that do not implement these extensions.
 
 ## Support for Path-Aware Networks (PAN)
 
-When operating over a path-aware network, endpoints can discover and utilize multiple disjoint or partially disjoint paths. This can be provided, for example, by {{SCION}} or other architectures such as {{SR}}. In such an environment, a single source–destination address pair may yield multiple distinct end-to-end paths, each with unique performance characteristics (e.g., latency, loss rate). These paths can be exposed to the transport layer via distinct Path IDs in {{MP-QUIC}}.
+When operating over a path-aware network, endpoints can discover and utilize multiple disjoint or partially disjoint paths. This can be provided, for example, by {{SCION}} or other architectures such as {{SR}}. In such an environment, a single source–destination address pair may yield multiple distinct end-to-end paths, each with unique performance characteristics (e.g., latency, loss rate). These paths can be exposed to the transport layer via distinct Path IDs in {{QUIC-MULTIPATH}}.
 
 This document does not prescribe how endpoints discover and enumerate available paths at the network layer. Rather, it assumes that a PAN can supply multiple viable routes between endpoints. Once discovered, each route is mapped to a unique Path ID, enabling the {{DMTP}} scheduling logic to treat them as distinct transport paths for deadline-aware streams.
 
@@ -158,7 +158,7 @@ The specific behavior is implementation-specific and MAY be configurable by the
 
 When deadlines are tight and packet losses frequent, relying solely on retransmissions may cause data to miss its deadline. To mitigate this risk, this extension optionally uses Adaptive FEC (AFEC) as proposed in {{QUIC-AFEC}}. AFEC can reduce the need for retransmissions, particularly in networks with random or bursty loss characteristics.
 
-When using AFEC with {{MP-QUIC}}, the Tag Type of the FEC_Tag MUST be set to 1 to indicate "Long Flow Usage". In turn, both source symbol packets and repair symbol packets MUST carry the FEC_Tag frame so that repair packets can be correctly matched to their corresponding source packets across different paths.
+When using AFEC with {{QUIC-MULTIPATH}}, the Tag Type of the FEC_Tag MUST be set to 1 to indicate "Long Flow Usage". In turn, both source symbol packets and repair symbol packets MUST carry the FEC_Tag frame so that repair packets can be correctly matched to their corresponding source packets across different paths.
 
 If multiple paths are available, FEC repair packets SHOULD be sent over a path different from the one carrying the source data. This de-correlates losses and increases the likelihood that repair symbols arrive even if other paths experience congestion or packet loss. The coding rate (i.e., the ratio of repair symbols to source symbols) MAY be configured on a per-stream basis, depending on the stream's tolerance for overhead versus its deadline sensitivity.
 
@@ -185,11 +185,11 @@ For accurate one-way delay measurements, endpoints MAY use synchronized clocks;
 1. Path-Aware Networks might provide direct metrics, such as path latency or bandwidth as part of path metadata.
 2. Active Probing: If the underlying network does not provide metrics, the endpoint MAY send periodic PING frames or small test packets along each active path.
 3. Path Measurement Frames: This draft introduces an optional DMTP_ACK frame ({{dmtp-ack-frame}}) for deeper path measurements, including timestamps of packet receipts to estimate per path one-way delay.
-4. Congestion windows, RTT estimates, and packet loss detection from {{MP-QUIC}}'s standard loss recovery can inform scheduling.
+4. Congestion windows, RTT estimates, and packet loss detection from {{QUIC-MULTIPATH}}'s standard loss recovery can inform scheduling.
 
 # Extension to Multipath QUIC
 
-This extension builds upon {{MP-QUIC}}. Below we list the protocol additions and modifications. Unless otherwise noted, all rules of MP-QUIC remain.
+This extension builds upon {{QUIC-MULTIPATH}}. Below we list the protocol additions and modifications. Unless otherwise noted, all rules of QUIC-MULTIPATH remain.
 
 ## Handshake Negotiation and Transport Parameter {#transport-parameter}
 
@@ -262,7 +262,7 @@ These calls let an application specify deadlines and priorities dynamically.
 
 # Security Considerations
 
-This extension retains all the security features and considerations of {{QUIC}}, {{QUIC-TLS}} and {{MP-QUIC}}.
+This extension retains all the security features and considerations of {{QUIC}}, {{QUIC-TLS}} and {{QUIC-MULTIPATH}}.
 Nevertheless, it introduces additional considerations:
 
 - Deadline Signaling: Knowledge of deadlines or priorities may be sensitive if it reveals application timing patterns or critical data intervals. Implementations SHOULD carefully handle metadata (e.g., by encrypting frames in 1-RTT packets).
@@ -294,4 +294,4 @@ TBD (2)                                            | DMTP_ACK            | {{dmt
 # Acknowledgments
 {:numbered="false"}
 
-The authors thank the QUIC working group and the designers of both {{MP-QUIC}} and {{QUIC-DTP}} for paving the way for deadline-aware features in QUIC. The concept of scheduling data with deadlines over multiple paths builds on numerous discussions around partial reliability, adaptive FEC, and optimal path selection.
+The authors thank the QUIC working group and the designers of both {{QUIC-MULTIPATH}} and {{QUIC-DTP}} for paving the way for deadline-aware features in QUIC. The concept of scheduling data with deadlines over multiple paths builds on numerous discussions around partial reliability, adaptive FEC, and optimal path selection.