Re: Add deadline awareness to QUIC

[Ian Swett <[e-mail]>]

I can see how that would be useful, though I wonder if Christian (
draft-huitema-quic-ts
<https://datatracker.ietf.org/doc/draft-huitema-quic-ts/>) or my (
draft-smith-quic-receive-ts
<https://datatracker.ietf.org/doc/draft-smith-quic-receive-ts>/) timestamp
draffs might also provide the same delivery time functionality in a more
general way?

On Wed, Dec 7, 2022 at 7:59 AM Shihang(Vincent) <shihang9=
[e-mail]> wrote:

> Hi Ian,
>
> Another author of DTP here.
>
> Thanks for your comment. Glad to hear that the deadline feature is useful
> inside Chromium. Can you talk a little bit more about those use cases?
>
>
>
> You are right that a simple deadline-awareness feature does not require
> new frames. We add new frames to build a feedback loop of the deadline
> delivery. The BLOCK_INFO frame which contains the start time stamp is sent
> from sender to receiver. The receiver calculates the difference of the
> expected deadline and the actual block completion time and sent it back to
> the sender. Sender then uses it to calibrate its estimation of delivery
> time. The sender can infer it from the ACK but it is affected by the ACK
> policy such as ACK frequency. We will update the draft to reflect these
> design considerations.
>
>
>
> Best,
>
> Hang
>
>
>
> *From:* QUIC <[e-mail]> *On Behalf Of *Ian Swett
> *Sent:* Monday, November 21, 2022 7:17 PM
> *To:* Chuan Ma <[e-mail]>
> *Cc:* [e-mail]; Christian Huitema <[e-mail]>;
> [e-mail]; [e-mail]
> *Subject:* Re: Add deadline awareness to QUIC
>
>
>
> 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
>
>
>
> Ian
>
>
>
> On Tue, Nov 15, 2022 at 11:03 AM Chuan Ma <[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]>
> wrote:
>
>
>
>
>
> On Mon, Nov 14, 2022 at 1:05 PM Christian Huitema <[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/ and implemented a
> > protocol based on QUIC called DTP (Deadline-aware Transport Protocol) in
> > 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). 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
> >
>
>