Dear QUIC WG,
A quick heads-up that we now have a prototype of deadline-aware streams
based on picqoquic:
https://github.com/netsys-lab/picoquic
Prototype notes:
https://github.com/netsys-lab/picoquic/blob/master/deadline_aware_streams.md
Best regards,
Tony John
On 06/06/2025 06:43, Tony John wrote:
Dear QUIC WG,
Thank you again Christian Huitema, Martin Thomson, and others for your
valuable feedback on our initial draft on Deadline Aware Streams in
QUIC-MULTIPATH. Based on your suggestions, we've now published version
-01:
https://datatracker.ietf.org/doc/draft-tjohn-quic-multipath-dmtp/01/
Key changes in -01:
* Terminology alignment: Replaced "MP-QUIC" with "[QUIC-MULTIPATH]"
throughout, following established naming conventions
* Simplified timing mechanism: Removed the custom DMTP_ACK frame in
favor of reusing the timestamp approach from
draft-smith-quic-receive-ts, improving composability with [QUIC]
and [QUIC-MULTIPATH]
* Broader applicability: Clarified that DEADLINE_CONTROL works also
with standard QUIC connections - multipath amplifies benefits but
isn't required
Next steps:
We're currently finalizing a proof-of-concept implementation of our
draft that we'll publish shortly.
We believe this revision addresses the key points raised on the list
and brings our draft a step closer to being “experiment-ready.”
Feedback of any kind is very welcome and appreciated.
Best regards,
Tony John
On 13/03/2025 16:33, Tony John wrote:
Thanks for your feedback. We’ll revise our terminology to
“[QUIC-MULTIPATH]” instead of “MP-QUIC,” and remove the DMTP_ACK
frames in favor of using the timestamp approach from
[draft-huitema-quic-ts-08] for more precise one-way delay
measurements. This should keep most of the features of our extension
composable with both [QUIC] and [QUIC-MULTIPATH].
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
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/
