Best regards, Tony John
On 12/03/2025 22:14, Christian Huitema wrote:
There is no such thing as "MP-QUIC". That acronym is never used in the multipath extension draft, and that's deliberate. There is only one QUIC protocol. I understand that you need a shorthand designation for your document, but it would be better to follow the established practice, such as [QUIC-TRANSPORT], [QUIC-TLS], etc. Maybe [QUIC-MULTIPATH].You can certainly define a new frame type that is only valid when your specified protocol extension has been negotiated. This is exactly why we have an extension mechanism: let researchers experiment. You define two new frames:* DEADLINE_CONTROL, which specify a deadline for data in a stream, and has no dependency on the multipath extension,* DMTP_ACK, which is an extension of the ACK/ACK_ECN to add a timestamp, and is not compatible with the PATH_ACK frame format defined in the multipath extension draft.There have been a lot of discussions in this working group about adding time information to acknowledgements. The basic format does include an ACK_DELAY element, which provides some information. You propose adding a 'timestamp'. I tried that, and got specific feedback: it is better to define an independent "time stamp" frame than to do yet another modification of the ACK format. In your case, following the design in https://datatracker.ietf.org/doc/html/draft-huitema-quic-ts-08 would have a big advantage: it could be composed with either the ACK frame of RFC 9000 or the PATH_ACK frame of [QUIC-MULTIPATH].-- Christian Huitema On 3/12/2025 10:13 AM, Tony John wrote:Many thanks for your valuable feedback and suggestions, which we would like to address as follows:We certainly agree that deadlines can benefit single-path QUIC and strict latency requirements don’t inherently require multiple paths. But, our motivation for targeting MP-QUIC is that deadlines and multipath have especially strong synergy. For instance:- Path Selection / Scheduling: In a multipath scenario, the sender can dynamically choose which path can still meet the deadline based on path-specific metrics. This is significantly more impactful when there is more than one path to choose from.- Loss Tolerance / FEC: When combined with forward error correction (FEC), leveraging multiple paths can greatly improve delivery probability before the deadline—particularly if losses are bursty or correlated on certain links. In a single-path setup, FEC usage is helpful but doesn’t offer the same resilience to path failures or unexpected congestion.Our current draft emphasizes multipath because that’s where we think the improvements are most pronounced.That said, some DMTP features, such as deadline signaling and partial reliability, can also be valuable over single-path, or in cases where an optimal path is chosen in a Path Aware Network. We will certainly consider this perspective in our ongoing work and possibly refine the draft to ensure that while multipath remains a primary focus, it remains optional, allowing implementations to leverage deadline-awareness even in single-path scenarios.Reason for a protocol extension rather than just an API:Some deadline-aware strategies can be implemented purely at the sender, especially with good RTT estimates or using timestamping techniques such as Christian Huitema’s arrival timing draft (draft-huitema-quic-ts-08). However, there are a few reasons we believe a small wire-level extension is valuable:- Receiver Coordination / Interoperability: By having an explicit frame that carries deadline information, the receiver gains clear signals that certain streams have a “hard” cutoff. This allows for smarter partial-reliability strategies—for instance, stopping the reassembly of data that’s already missed its window. Achieving that with only a sender-side heuristic is harder. Additionally, the proposed DMTP_ACK frame, provides better granularity for the sender to understand whether deadlines are actually being met in practice, which further improves scheduling accuracy.- Optional Forward Error Correction: In scenarios using FEC, the receiver needs to understand which repair symbols apply to which stream and for what deadline window. Standardizing that framing at the QUIC layer helps ensure interoperability, rather than requiring proprietary coordination or an out-of-band mechanism.- Consistent Implementation: Having a well-defined protocol extension (even if minimal) avoids the risk that every QUIC stack invents its own ad-hoc way of expressing deadlines. We believe that an agreed-upon extension fosters experimentation and reuse across implementations.We definitely see Christian Huitema’s arrival timing draft as complementary. Combining more precise packet-timing feedback with explicit deadlines could refine scheduling decisions further.We appreciate your insights on whether this belongs more in an API or in the protocol itself, and we welcome further discussion on how to scope these extensions.Best regards, Tony On 08/03/2025 09:39, Martin Thomson wrote:I realize that multipath transports might have a greater need for this sort of thing, but I don't see why this feature would be exclusive to multipath QUIC. Given that most delays are the result of common factors (in particular, the need to retransmit, flow control or congestion limits) and not multipath-specific factors (like path selection), this seems like it would be almost as useful without multipath.The bigger question is why this is a *protocol* as opposed to an *API*. A lot of this can be driven by a sender. Christian's arrival timing draft[1] wouldn't be essential -- you can always estimate pretty accurately when something might be received -- but it would help refine the timings.[1] https://datatracker.ietf.org/doc/html/draft-huitema-quic-ts-08 On Tue, Mar 4, 2025, at 17:09, Tony John wrote:Dear QUIC Working Group,Last year, we shared our proposal for integrating Deadline-Aware Streamsinto Multipath QUIC using DMTP [1] and we are very grateful for the feedback received from both the QUIC WG as well as the team working on the MP-QUIC extension. Meanwhile, we have followed-up on the suggestion to propose anadditional extension on top of MP-QUIC and we are pleased to share thatwe have now just uploaded a new I-D, Deadline Aware Streams in MP-QUIC(draft-tjohn-quic-multipath-dmtp-00) which addresses this. As this is aninitial version, our main objective is to gauge interest and solicit your feedback. Brief Recap of the Proposal: - Deadline Negotiation: Introduces a transport parameter and a DEADLINE_CONTROL frame so that endpoints can coordinate explicit deadlines for individual streams. - Smart Retransmissions & FEC: Integrates concepts from DMTP to make informed retransmission and scheduling decisions, and optionally use FEC, all while leveraging multiple paths. - Path-Aware Network Support: Takes advantage of path diversity (e.g., as offered by SCION) by mapping distinct paths into MP-QUIC path identifiers, which can improve reliability for streams with strict deadlines. Motivation Recap:As real-time applications and interactive use cases (teleoperation, live streaming, gaming) become more prevalent, there is a growing interest inmechanisms that help ensure data arrives before a specific deadline. MP-QUIC provides the framework to use multiple paths, but it doesn’t offer explicit support for deadline-aware streams. Our draft aims to address that gap in a way that remains interoperable with unmodified MP-QUIC endpoints. Feedback & Next Steps: We would greatly appreciate the Working Group’s input on the following aspects:- Adoption Interest: Would the WG be open to considering this extensionfor an experimental track? Do you see this aligning with the direction of QUIC’s multipath evolution? - Technical Feasibility: Are there major gaps in the design that need further exploration?- Potential Challenges: Do you see significant hurdles that could limitadoption? You can find the text of the draft and its source here: - Datatracker: https://datatracker.ietf.org/doc/draft-tjohn-quic-multipath-dmtp/ - GitHub: https://github.com/netsys-lab/mpquic-dmtp-draft We truly appreciate the feedback received so far and we would be veryinterested in continued input from this working group on whether and howdeadline signaling might best fit into the QUIC family of standards. Thank you for your time. I look forward to your comments and any guidance you may have. Best regards, Tony John Research Associate Otto-von-Guericke-University Magdeburg, Germany[1] https://mailarchive.ietf.org/arch/msg/quic/TnKyqN6XnaUEYt9zyDXc1soN9DM/
