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 Streams > into 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 an > additional extension on top of MP-QUIC and we are pleased to share that > we 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 an > initial 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 in > mechanisms 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 extension > for 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 limit > adoption? > > 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 very > interested in continued input from this working group on whether and how > deadline 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/
