Hi Ian,
Thank you for your feedback. While it's possible to implement
deadline-aware streams in Multipath QUIC using implementation-specific
APIs, this approach may lack endpoint coordination because deadlines are
not communicated between endpoints through the protocol. By introducing
a transport parameter and a custom frame, endpoints can negotiate
support and exchange deadline information directly within the protocol,
enabling coordinated scheduling decisions at the transport layer.
Standardizing this mechanism avoids the limitations of
implementation-specific solutions, promoting wider adoption and
interoperability of deadline-aware streams across different
implementations of Multipath QUIC.
Best regards,
Tony
On 10/31/2024 14:23, Ian Swett wrote:
I'm unclear what is needed from QUIC or Multipath QUIC? One can
already implement deadline aware streams and expose that as an API,
but I don't see why the wire format would need to change or why a
transport param would be necessary?
Doing deadline aware scheduling over multiple paths seems like a
difficult problem to me, and likely better suited to research than the
IETF, but I'm not an expert.
Ian
On Thu, Oct 31, 2024 at 7:50 AM Marten Seemann
<[email protected]> wrote:
The paper is paywalled. I don't have access, and I'd assume that
this applies to many participants on this mailing list.
On Thu, 31 Oct 2024 at 17:12, Tony John <[email protected]> wrote:
Dear QUIC Working Group,
I would like to initiate a discussion on integrating
deadline-aware streams as an extension to the Multipath QUIC
protocol. Given the increasing demand for real-time
applications such as teleoperation, live video streaming, and
online gaming, there's a growing need for transport protocols
that can efficiently handle strict latency requirements.
Motivation
Multipath QUIC enhances performance by utilizing multiple
paths simultaneously, but it currently lacks mechanisms to
guarantee data delivery within specific timeframes.
Introducing deadline-aware streams to Multipath QUIC could
enable applications to meet stringent latency constraints,
optimizing for low-latency and high-reliability scenarios.
Additionally, the ability to have multiple paths using the
same 4-tuple opens up the possibility of leveraging paths from
path-aware networks like SCION, source routing, and others.
This expands the pool of available paths beyond traditional
IPv4 and IPv6 routes, potentially increasing the effectiveness
of deadline-aware mechanisms like those proposed in the
Deadline-aware Multipath Transport Protocol (DMTP).
Relevant Discussions
I would like to acknowledge the previous discussion
<https://mailarchive.ietf.org/arch/msg/quic/Ie6Ju6cNCocNNktldJJrvZfsXQ8/>on
adding deadline awareness to QUIC. The discussion indicates
interest in deadline-aware mechanisms and their applicability
to QUIC.
Proposal
Building upon these ideas, I propose integrating
deadline-aware streams into Multipath QUIC as an optional
extension. The key aspects of the proposal are:
*
New Transport Parameter and Frame Type: Introduce a new
transport parameter to signal support for deadline-aware
streams during the QUIC handshake and define a new frame
type called DEADLINE_CONTROLto signal deadlines for
specific streams.
*
Leveraging DMTP Concepts: Utilize strategies from the
Deadline-aware Multipath Transport Protocol (DMTP), such
as smart retransmissions and Forward Error Correction
(FEC), to optimize packet delivery based on latency deadlines.
*
Custom Scheduler and Congestion Controller: Implement
DMTP's mechanisms as a custom scheduler and congestion
controller within the Multipath QUIC framework.
How DMTP Fits In
DMTP is tailored for deadline-sensitive communication over
multiple paths. Its key concepts include:
*
Path Optimization: Dynamically selecting paths based on
metrics like latency, bandwidth, and packet loss,
complementing Multipath QUIC's ability to manage multiple
paths effectively.
*
Adaptive FEC: Integrating FEC to reduce the need for
retransmissions, enhancing Multipath QUIC's congestion
control mechanisms.
*
Smart Retransmissions: Retransmitting packets only if they
are predicted to meet the deadline, avoiding unnecessary
retransmissions and improving efficiency.
For more detailed information on DMTP, please refer to our
paper
<https://doi.org/10.23919/IFIPNetworking57963.2023.10186417>.
We have developed a prototype implementation of DMTP, which we
plan to open-source shortly.
Request for Feedback
I am interested in the community's perspective on this proposal:
*
Value of Exploration: Do you see value in exploring
deadline-aware streams as an extension to Multipath QUIC?
*
Potential Challenges: Are there potential challenges or
compatibility concerns we should be aware of?
I would greatly appreciate any thoughts or guidance on how
best to proceed. Thank you for considering this proposal. I
look forward to your feedback and the possibility of
discussing this further.
Best regards,
M.Sc. Tony John
Research Associate
Otto-von-Guericke-University Magdeburg, Germany
