diff --git a/.gitea/workflows/test.yml b/.gitea/workflows/test.yml deleted file mode 100644 index 8d1c8b6..0000000 --- a/.gitea/workflows/test.yml +++ /dev/null @@ -1 +0,0 @@ - diff --git a/quic-message.bib b/quic-message.bib index d0ba984..7ecd424 100644 --- a/quic-message.bib +++ b/quic-message.bib @@ -9,3 +9,19 @@ mrnumber = {MR0885560}, doi = {10.1007/BF01208956}, } +@ARTICLE{FlEC-23, + + author={Michel, François and Cohen, Alejandro and Malak, Derya and De Coninck, Quentin and Médard, Muriel and Bonaventure, Olivier}, + + journal={IEEE/ACM Transactions on Networking}, + + title={FlEC: Enhancing QUIC With Application-Tailored Reliability Mechanisms}, + + year={2023}, + + volume={31}, + + number={2}, + pages={606-619}, + doi={10.1109/TNET.2022.3195611} +} diff --git a/quic-message.tex b/quic-message.tex index e123bbc..1bca86d 100644 --- a/quic-message.tex +++ b/quic-message.tex @@ -43,14 +43,28 @@ The rapid evolution of the internet has propelled the demand for real-time streaming applications, such as video conferencing, live streaming, and online gaming. To meet the growing requirements of these applications, protocols have continuously evolved, aiming to provide efficient and reliable data transmission over the network. One such protocol, QUIC (Quick UDP Internet Connections), has gained considerable attention due to its ability to enhance web performance by reducing latency and improving security. -However, in its current state, QUIC faces challenges when it comes to supporting real-time streaming applications, particularly those relying on the Real-Time Transport Protocol (RTP) and WebRTC (Web Real-Time Communication) framework. +% However, in its current state, QUIC faces challenges when it comes to supporting real-time streaming applications, particularly those relying on the Real-Time Transport Protocol (RTP) and WebRTC (Web Real-Time Communication) framework. +However, in its current state, QUIC faces challenges when it comes to supporting real-time streaming applications, particularly those who require a mix of reliable and unreliable data transfer at the same time. +While QUIC offers an unreliable datagramm service via the QUIC Datagram Extension, we argue that this is not sufficient for scenarios, where an application needs both reliable and unreliable data transmission. -This paper presents an extension to the QUIC protocol that aims to address these challenges by introducing a message service model and flexible reliability on the message level. Our primary objective is to make QUIC well-suited for real-time streaming applications, enabling seamless integration with RTP streaming and WebRTC. -The introduction of a message service model into QUIC serves as a fundamental enhancement, empowering applications with the ability to send and receive discrete messages, rather than relying solely on QUIC's existing stream abstraction. By doing so, we enable a more efficient and streamlined data exchange mechanism, tailored to the requirements of real-time streaming applications. This message-based approach allows for improved control over packetization, prioritization, and synchronization, ultimately contributing to reduced latency and enhanced user experience. -In addition to the message service model, we introduce flexible reliability at the message level, offering finer-grained control over reliability mechanisms. This enhancement allows streaming applications to selectively apply reliability mechanisms based on the criticality and time sensitivity of individual messages. By adapting the reliability settings according to the specific requirements of real-time streaming, we strike a balance between efficient data delivery and minimizing latency, thereby enabling smoother playback and real-time interaction. -With the proposed extension, we envision QUIC becoming a reliable and efficient transport protocol for real-time streaming scenarios. By making QUIC compatible with RTP streaming and WebRTC, we unlock the potential for a wide range of applications, including video conferencing, live streaming platforms, online gaming, and more. Seamless integration with existing technologies empowers developers to leverage the benefits of QUIC while maintaining interoperability with established frameworks. -This paper is structured as follows: Section 2 provides an overview of the QUIC protocol and its current limitations for real-time streaming applications. Section 3 details our proposed message service model, outlining its design principles and mechanisms. Section 4 focuses on the flexible reliability enhancements, explaining the rationale behind its introduction and the different reliability options available. Section 5 presents our experimental evaluation, showcasing the performance improvements achieved through our extension. Finally, Section 6 summarizes the contributions of this work and discusses potential future directions. -In conclusion, this paper aims to extend the QUIC protocol by introducing a message service model and flexible reliability at the message level. By doing so, we strive to make QUIC ready for real-time streaming applications, particularly those relying on RTP streaming and WebRTC. Our approach offers improved efficiency, reduced latency, and enhanced user experience, contributing to the advancement of real-time communication over the internet. +This paper presents an extension to the QUIC protocol that aims to address these challenges by introducing a message service model and flexible reliability on the message level. +Our primary objective is to make QUIC well-suited for real-time streaming applications, and possibly enabling seamless integration with RTP streaming and WebRTC in the future. +The introduction of a message service model into QUIC serves as a fundamental enhancement, empowering applications with the ability to send and receive discrete messages, rather than relying solely on QUIC's existing stream abstraction or rigid datagram extension. +By doing so, we enable a more efficient and streamlined data exchange mechanism, tailored to the requirements of real-time streaming applications. This message-based approach allows for improved control over packetization, prioritization, and synchronization, ultimately contributing to reduced latency and enhanced user experience. +In addition to the message service model, we introduce flexible reliability at the message level, offering finer-grained control over reliability mechanisms. +This enhancement allows streaming applications to selectively apply reliability mechanisms based on the criticality and time sensitivity of individual messages. +By adapting the reliability settings according to the specific requirements of real-time streaming, we strike a balance between efficient data delivery and minimizing latency, thereby enabling smoother playback and real-time interaction. +With the proposed extension, we envision QUIC becoming a reliable and efficient transport protocol for real-time streaming scenarios. +% By making QUIC compatible with RTP streaming and WebRTC, we unlock the potential for a wide range of applications, including video conferencing, live streaming platforms, online gaming, and more. +% Seamless integration with existing technologies empowers developers to leverage the benefits of QUIC while maintaining interoperability with established frameworks. +This paper is structured as follows: Section 2 provides an overview of the QUIC protocol and its current limitations for real-time streaming applications. +Section 3 details our proposed message service model, outlining its design principles and mechanisms. +Section 4 focuses on the flexible reliability enhancements, explaining the rationale behind its introduction and the different reliability options available. +Section 5 presents our experimental evaluation, showcasing the performance improvements achieved through our extension. +Finally, Section 6 summarizes the contributions of this work and discusses potential future directions. +In conclusion, this paper aims to extend the QUIC protocol by introducing a message service model and flexible reliability at the message level. +By doing so, we strive to make QUIC ready for real-time streaming applications, particularly those who require reliable and unreliable data transmission at the same time. +Our approach offers improved efficiency, reduced latency, and enhanced user experience, contributing to the advancement of real-time communication over the internet. % QUIC is a general purpose transport-layer protocol initially developed by Google in 2012. % QUIC multiplexes application data as Streams into packets via frames. @@ -75,12 +89,59 @@ In conclusion, this paper aims to extend the QUIC protocol by introducing a mess % With the transmission of unreliable data, QUIC can become a viable choice to transmit real-time data and for applications. \section{Background} -The IP layer provides a best effort service for packets between endpoints. -The transport layer provides services like delivery to application, sequencing, timing, reliability and congestion control, to name only a few. -Real-time multimedia applications have historically used transport protocols that prefer timeliness over reliability. + +% The IP layer provides a best effort service for packets between endpoints. +% The transport layer provides services like delivery to application, sequencing, timing, reliability and congestion control, to name only a few. +% Real-time multimedia applications have historically used transport protocols that prefer timeliness over reliability. +The QUIC Unreliable Datagram Extension adds support for unreliable datagram delivery within QUIC connections. +This extension recognizes the need for certain applications to prefer reduced latency over guaranteed delivery. +The QUIC Datagram Extension is a first step to support more service models in QUIC. +However, the problem with the QUIC Datagram Extension is that it is not flexible enough, especially when both reliable and unreliable services must be accommodated. +% The QUIC Datagram relies on so called DATAGRAM frames, which are sent in QUIC packets. +% However, the DATAGRAM frames are created by the application, which does not have any knowledge about the state of the network. +% This means that the application must make decisions that are relevant later without any knowledge of the current state of the protocol. +In the QUIC protocol, DATAGRAM frames are sent in QUIC packets, but DATAGRAM frames are created by the application itself. +This poses a problem as the application doesn't have information about the network's current state, leading to uninformed decisions about protocol-related matters. +DATAGRAM frames in particular cannot be fragmented, which can cause problems for the protocol when it comes to muxing the frames into packets. + +Let's assume a scenario where we one connection with three logical streams. +Stream 1 consist of signaling data, with a reliable service model and hightest priority, Stream 2 is a video feed with medium priority, transmitted via DATAGRAMs, Stream 3 is bulk data transfer with low priority. + +If the application sends enough DATAGRAMs to satisfy the currently available bandwidth, the other Streams will starve, regardless of the priorities desired by the application. +This is one kind of starvation and it is caused by the application not having any knowledge about the currently available bandwidth. +Furthermore, it violates the priority of the application, because the application wanted to prioritize Stream 1 over Stream 2 and Stream 2 over Stream 3. + +But even if you try to preserve the priorities from the application on the protocol level, the lack of fragmentation can cause accidental starvation. +Let's assume that the protocol tries to follow the priorities of the application when it creates a packet. +Then the protocol would try to fill the packet with data from Stream 1, then Stream 2 and finally Stream 3. +However, if the protocol has written data from Stream 1, it is possible that the DATAGRAMs from Stream 2 do not fit into the packet. +The protocol would then have to send the packet without the DATAGRAMs from Stream 2, but with data from Stream 3. +This again violates the priorities of the application, because the application wanted to prioritize Stream 2 over Stream 3. + +To solve this issue one of two things must happen. +Either the application must have knowledge about the current state of the protocol, or we must allow protocol to fragment the data from Stream 2. +Our extension provides the ability to fragment data from Stream 2, which solves the problem of starvation. \section{Related Work} +There is a large body of work on transport protocols for real-time communication. +The most prominent example is the Real-time Transport Protocol (RTP) \cite{rfc3550} and WebRTC \cite{webrtc}. +RTP is a transport protocol for real-time data, which is used in conjunction with a signaling protocol like SIP or H.323. +WebRTC is a framework for real-time communication in the browser, which uses RTP and other protocols like SCTP and SRTP. +However, WebRTC is not a transport protocol itself, but a framework for real-time communication in the browser. +WebRTC uses multiple transport protocols for different purposes. +The XHR, SSE and Websocket protocol with an underlying TCP connection, as well as (S)RTP and SCTP. +Nonetheless, the use of multiple transport protocols is not ideal, because it requires multiple stacks and the overhead of multiple connections. +Furthermore, all of these protocols have their own congestion mechanisms, which makes QoS difficult. + +SCTP is a transport protocol that is used in WebRTC for data channels. +SCTP is a message-oriented transport protocol, which means that it provides a message-oriented service to the application. +Furthermore, it provides a configurable reliability service, which can be configured to be reliable, partially reliable or unreliable. +In that sense it is very similar to our extension, but it faces difficulties in deployment and protocol complexity. +Our extension is designed to be to only make minimal changes to QUIC, enhancing the deployability and to co-exist with the byte-stream service model that QUIC already provides. + + + \section{RAPID Design and Implementation} TODO Motivation