OK, top-of-head response to the idea of a deadline-aware transport, not the implementation. My company is doing on-line ad auctions, which typically have a deadline of 120 milliseconds, from request to the last packet of the response. The deadline varies on a recipient-by-recipient basis, and could be less, or could stretch out or 300 milliseconds. I could stretch the window a few packet-times if I was already processing a response, but I would not welcome a "here's the first byte, the rest will be along next week" response (;-)) I strongly suspect a protocol mechanism wouldn't buy me anything I can't do in application code. --dave On 11/14/22 18:18, Dave Taht via Bloat wrote: ---------- Forwarded message --------- From: Chuan Ma Date: Mon, Nov 14, 2022 at 10:21 AM Subject: Add deadline awareness to QUIC To: Cc: 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 -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest dave.collier-brown@indexexchange.com | -- Mark Twain CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.