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 >
- Proposal for Integrating Deadline-Aware Streams i… Tony John
- Re: Proposal for Integrating Deadline-Aware Strea… Marten Seemann
- Re: Proposal for Integrating Deadline-Aware Strea… Ian Swett
- Re: Proposal for Integrating Deadline-Aware Strea… Tony John
- Re: Proposal for Integrating Deadline-Aware Strea… Tony John