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_CONTROL to
>    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
>
>

Reply via email to