Re: Proposal for Integrating Deadline-Aware Streams into Multipath QUIC using DMTP

Tony John <tony.john@ovgu.de> Thu, 31 October 2024 16:26 UTC

Return-Path: <tony.john@ovgu.de>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39474C1519A8 for <quic@ietfa.amsl.com>; Thu, 31 Oct 2024 09:26:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGzLMXZIXgpg for <quic@ietfa.amsl.com>; Thu, 31 Oct 2024 09:26:45 -0700 (PDT)
Received: from mail.ovgu.de (mail.ovgu.de [141.44.1.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9389C151980 for <quic@ietf.org>; Thu, 31 Oct 2024 09:26:44 -0700 (PDT)
Received: from [10.1.0.7] (unknown [141.44.25.153]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ovgu.de (Postfix) with ESMTPSA id 30C1AA0A41; Thu, 31 Oct 2024 17:26:41 +0100 (CET)
Content-Type: multipart/alternative; boundary="------------blrEVFHdj3ViQb8mNAvYWIII"
Message-ID: <2fe56cd3-35fb-4165-9fee-cf2ff64a5e77@ovgu.de>
Date: Thu, 31 Oct 2024 17:26:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Proposal for Integrating Deadline-Aware Streams into Multipath QUIC using DMTP
To: Marten Seemann <martenseemann@gmail.com>
References: <01f5c2ad-2129-495d-9385-5bcdc65d7467@ovgu.de> <CAOYVs2pDMpgWtUb48mL8phAJbrkZ826xGf94nO-BgPjLfnEhzQ@mail.gmail.com>
Content-Language: en-US
From: Tony John <tony.john@ovgu.de>
In-Reply-To: <CAOYVs2pDMpgWtUb48mL8phAJbrkZ826xGf94nO-BgPjLfnEhzQ@mail.gmail.com>
Message-ID-Hash: PK2W4PPGYCKZX2A4XC3LV54YQILJQUPC
X-Message-ID-Hash: PK2W4PPGYCKZX2A4XC3LV54YQILJQUPC
X-MailFrom: tony.john@ovgu.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-quic.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: quic@ietf.org, David Hausheer <david.hausheer@gmail.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Ndf2P_TzDpCVEvd3AEvMuWp-Upo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Owner: <mailto:quic-owner@ietf.org>
List-Post: <mailto:quic@ietf.org>
List-Subscribe: <mailto:quic-join@ietf.org>
List-Unsubscribe: <mailto:quic-leave@ietf.org>

Thanks for bringing this to my attention! I have an alternate link to 
the paper that isn’t behind a paywall: 
https://netsec.ethz.ch/publications/papers/john-dmtp-2023.pdf

Best regards

Tony John

On 31/10/2024 12:49, Marten Seemann 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 <tony.john@ovgu.de> 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
>