I guess you are referring to the lifetime message property (see https://www.ietf.org/archive/id/draft-ietf-taps-interface-18.html#section-9.1.3.1). We are improving the deadline delivery by deadline-aware scheduling and redundancy(FEC). The scheduling is doable on top of QUIC (may involve a lot of timer overhead). But the FEC requires the knowledge of packet boundary which can not work on top of QUIC, at least not QUIC stream.
-----Original Message----- From: QUIC <[email protected]> On Behalf Of Michael Welzl Sent: Thursday, December 8, 2022 6:35 PM To: François Michel <[email protected]> Cc: Ian Swett <[email protected]>; Chuan Ma <[email protected]>; [email protected]; Christian Huitema <[email protected]>; [email protected]; [email protected] Subject: Re: Add deadline awareness to QUIC FWIW, the TAPS API has deadline-awareness, and QUIC can operate underneath it… Sent from my iPhone > On 8 Dec 2022, at 11:26, François Michel <[email protected]> wrote: > > Hi, > > I wasn't aware of this ttl parameter in Chrome. We also studied quite a bit > the addition of deadline-awareness to QUIC a while ago on a ToN article right > there, see Section VIII: > https://dial.uclouvain.be/pr/boreal/object/boreal%3A264704/datastream/PDF_01/view > > In short, we added an API to our QUIC implementation to be able to send > "messages" with deadlines attached to it, each message being sent on its > dedicated QUIC stream. Attaching a deadline to a message means that its > stream must be totally delivered within that time, so I guess the ttl field > of Chrome behaves similarly. This allowed us to schedule FEC in a more clever > way, and it might be the case for multipath scheduling too. For instance with > FEC we could spare a lot of bandwidth by protecting several video frames at > once using the deadline and framerate information (Figure 16 in the article). > > That being said, we did not make any specific protocol modification to use > deadlines, we just modified the API to be able to attach deadlines to > streams, like the ttl feature of Chrome. That affected the stream scheduling > and FEC scheduling, but no specific frame was required on our side so the > QUIC specification stayed unmodified. > > Looking at MoQ and Webtransport, it could be useful to already provide > deadline information from the WebTransport API and forward this info to QUIC > to be able to do clever streams/fec/multipath/whatever scheduling. > > Right now I am working on adding deadline awareness on our new FEC implem on > top of quiche-cf, so do not hesitate to reach out to me if you have any > question or comment. > > Cheers, > > François > >> On 21/11/22 12:16, Ian Swett wrote: >> This looks like it might be conflating a few features, some of which are >> very media specific and some which are more general, such as prioritization >> and deadline awareness. >> I may have missed it, but I'm not sure I understand why the deadline >> awareness requires a new frame. For low latency media, the sender typically >> knows what the deadline is, so it has no need to communicate it to the peer, >> unless this design has relays in mind. If so, Media over QUIC is even more >> the right venue for this. >> For example, the Chromium QUIC code has had a ttl feature for a few years >> that we've used for various use cases: >> https://source.chromium.org/chromium/chromium/src/+/main:net/third_party/quiche/src/quiche/quic/core/quic_stream.cc;l=1384 >> >> <https://source.chromium.org/chromium/chromium/src/+/main:net/third_party/quiche/src/quiche/quic/core/quic_stream.cc;l=1384> >> Ian >> On Tue, Nov 15, 2022 at 11:03 AM Chuan Ma <[email protected] >> <mailto:[email protected]>> wrote: >> Hello Huitema and Sarikaya, thanks for the reply. >> You are correct that some of our designs are similar to MoQ answers. >> For example, we both use partial delivery to improve real-time app >> delivery. Actually, we sent the draft to the MoQ mailing list and >> discussed the detailed design and which layer to place the module. >> But our draft focuses on providing general deadline-aware transport >> service as a QUIC extension which is out of the scope of MoQ. MoQ >> builds on top of QUIC and is explicitly tailored to media delivery. >> We would like to hear the opinion of the QUIC community to see the >> need for such a *general deadline-aware transport service*. >> On Tue, Nov 15, 2022 at 7:12 AM Behcet Sarikaya >> <[email protected] <mailto:[email protected]>> wrote: >> On Mon, Nov 14, 2022 at 1:05 PM Christian Huitema >> <[email protected] <mailto:[email protected]>> wrote: >> Hello Chuan Ma, >> Your draft aligns very much with some of the options >> investigated for >> "media over QUIC". Have you considered participating in that >> working group? >> I agree, this looks very much like media transmission material. >> Behcet >> -- Christian Huitema >> On 11/14/2022 10:20 AM, Chuan Ma wrote: >> > Dear all: >> > >> > I'm Chuan Ma from Tsinghua University. I want to discuss >> the deadline >> > awareness of the current application and whether we >> should add it to the >> > QUIC protocol. >> > >> > Applications may have specific deadline requirements for >> data transmission. >> > For instance, a video conference application may require >> sending the data >> > with a deadline of 200ms to enable live interaction. The >> application may >> > drop the data that misses the deadline, even if the data >> has already >> > reached the other end. In this case, it is possible to >> drop the data after >> > the given deadline from the sender to save bandwidth and >> decrease queuing >> > time. Deadline requirement is also helpful to offer >> deadline-aware >> > scheduling combined with QUIC stream priority. Such >> scheduling methods can >> > increase the punctuality of QUIC and allow more data to >> arrive on time. It >> > is possible to extend QUIC and offer deadline-aware >> transport as a service. >> > >> > Nowadays, deadline-aware data transmission is getting >> more and more >> > popular. Applications that emphasize real-time >> interaction, such as VR/AR, >> > gaming, and video conference, are drawing more and more >> attention. So >> > deadline-aware transport has a lot of use cases. However, >> currently, it is >> > the application that is responsible for realizing >> deadline-aware transport. >> > This transport service should be offered by the transport >> protocol but not >> > be left to the application. It is reasonable to provide >> such transport >> > service in a new transport protocol, and QUIC is a good base. >> > >> > We wrote a draft to show this idea in >> > https://datatracker.ietf.org/doc/draft-shi-quic-dtp/ >> <https://datatracker.ietf.org/doc/draft-shi-quic-dtp/> and >> implemented a >> > protocol based on QUIC called DTP (Deadline-aware >> Transport Protocol) in >> > https://github.com/STAR-Tsinghua/DTP.git >> <https://github.com/STAR-Tsinghua/DTP.git>. We also built a >> live stream >> > prototype application to compare the performance between >> DTP and QUIC ( >> > https://github.com/STAR-Tsinghua/LiveEvaluationSystem.git >> <https://github.com/STAR-Tsinghua/LiveEvaluationSystem.git>). We >> found that >> > DTP outperformed QUIC in improving data transmission >> punctuality and saving >> > bandwidth resources. We published the paper in ICNP22 and >> built several >> > systems like proxy and tunnel based on DTP. It would be a >> good idea to give >> > this method a try. >> > >> > We'd like to know what you think about this topic. Please >> let us know if >> > you have any comments. >> > >> > Best regards. >> > >> > Chuan Ma >> > >
