Hi, > On Dec 9, 2022, at 8:48 AM, Shihang(Vincent) <[email protected]> wrote: > > 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).
Yes. > 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. That seems orthogonal to my statement about TAPS: my comment was an add-on to the mention of the TTL parameter in the email from Francois below. I just meant to say that TAPS offer such a parameter too. Cheers, Michael > > -----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 >>>> >> > >
