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= [email protected]> 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 <[email protected]> *On Behalf Of *Ian Swett > *Sent:* Monday, November 21, 2022 7:17 PM > *To:* Chuan Ma <[email protected]> > *Cc:* [email protected]; Christian Huitema <[email protected]>; > [email protected]; [email protected] > *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 <[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]> > wrote: > > > > > > On Mon, Nov 14, 2022 at 1:05 PM Christian Huitema <[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/ 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 > > > >
