Re: Add deadline awareness to QUIC

[Michael Welzl <[e-mail]>]

Hi,

> On Dec 9, 2022, at 8:48 AM, Shihang(Vincent) <[e-mail]> 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 <[e-mail]> On Behalf Of Michael Welzl
> Sent: Thursday, December 8, 2022 6:35 PM
> To: François Michel <[e-mail]>
> Cc: Ian Swett <[e-mail]>; Chuan Ma <[e-mail]>; [e-mail]; Christian Huitema <[e-mail]>; [e-mail]; [e-mail]
> 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 <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> 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
>>>   <[e-mail] <mailto:[e-mail]>> wrote:
>>>       On Mon, Nov 14, 2022 at 1:05 PM Christian Huitema
>>>       <[e-mail] <mailto:[e-mail]>> 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
>>>> 
>> 
> 
>