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 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/
