harlequix/quic-message
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

adjustments

Browse Source
This commit is contained in:
Sebastian Rust
2023-08-07 10:37:47 +02:00
parent aea82e9242
commit 036e411cfd
1 changed files with 31 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

50
quic-message.tex
View File

@@ -40,27 +40,39 @@
% - benefits: one handshake, one connection % - benefits: one handshake, one connection
% - single congestion control % - single congestion control
\section{Introduction} \section{Introduction}
QUIC is a general purpose transport-layer protocol initially developed by Google in 2012. The rapid evolution of the internet has propelled the demand for real-time streaming applications, such as video conferencing, live streaming, and online gaming.
QUIC multiplexes application data as Streams into packets via frames. To meet the growing requirements of these applications, protocols have continuously evolved, aiming to provide efficient and reliable data transmission over the network.
These Streams provide a TCP-like reliable, ordered byte-stream transmission to the application. 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, applications which also require transmission of real-time data usually prefer unreliable transmission of data. 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, depending on the application, other and more complex service models may also required for end-user satisfaction.
To highlight the need for different service models in the same logical connection, we focus on a video meeting platform like Zoom, Jitsi or Big Blue Button, to name only a few.
Such a meeting requires a reliable transmission service for data such as text, file sharing or signaling and control information.
The transmission of real-time video and audio traffic is not suited for a reliable service model.
In fact, the inherent challenges of transmitting real-time traffic are exacerbates by a reliable service model. 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.
Whenever a reliable connection tries to fix a gap in the byte-stream by retransmission, it possibly delays the sending of new data or creates a HOL blocking, causing fresh data to arrive too late. 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.
To address the HOL blocking issue, QUIC uses streams, which are multiplexed into one connection but independent of each other, ensuring that missing or late data in one stream does not block another stream. 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.
Nevertheless, the HOL blocking still persists within a stream, due to the byte-stream model. 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.
One protocol which tries to support more service models and is specifically designed for multimedia communication is WebRTC. % QUIC is a general purpose transport-layer protocol initially developed by Google in 2012.
WebRTC achieves this by using multiple transport protocols itself for different purposes. % QUIC multiplexes application data as Streams into packets via frames.
The XHR, SSE and Websocket protocol with an underlying TCP connection, as well as SRTP and SCTP. % These Streams provide a TCP-like reliable, ordered byte-stream transmission to the application.
Nonetheless TODO: why multiple stack are bad % % However, applications which also require transmission of real-time data usually prefer unreliable transmission of data.
% However, depending on the application, other and more complex service models may also required for end-user satisfaction.
In this paper we present RAPID, an QUIC extension which adds the transmission of unreliable, unordered chunks of data, so called messages to QUIC. % To highlight the need for different service models in the same logical connection, we focus on a video meeting platform like Zoom, Jitsi or Big Blue Button, to name only a few.
With the transmission of unreliable data, QUIC can become a viable choice to transmit real-time data and for applications. % Such a meeting requires a reliable transmission service for data such as text, file sharing or signaling and control information.
% The transmission of real-time video and audio traffic is not suited for a reliable service model.
%
% In fact, the inherent challenges of transmitting real-time traffic are exacerbates by a reliable service model.
% Whenever a reliable connection tries to fix a gap in the byte-stream by retransmission, it possibly delays the sending of new data or creates a HOL blocking, causing fresh data to arrive too late.
% To address the HOL blocking issue, QUIC uses streams, which are multiplexed into one connection but independent of each other, ensuring that missing or late data in one stream does not block another stream.
% Nevertheless, the HOL blocking still persists within a stream, due to the byte-stream model.
%
% One protocol which tries to support more service models and is specifically designed for multimedia communication is WebRTC.
% WebRTC achieves this by using multiple transport protocols itself for different purposes.
% The XHR, SSE and Websocket protocol with an underlying TCP connection, as well as SRTP and SCTP.
% Nonetheless TODO: why multiple stack are bad
%
% In this paper we present RAPID, an QUIC extension which adds the transmission of unreliable, unordered chunks of data, so called messages to QUIC.
% With the transmission of unreliable data, QUIC can become a viable choice to transmit real-time data and for applications.
\section{Background} \section{Background}
The IP layer provides a best effort service for packets between endpoints. The IP layer provides a best effort service for packets between endpoints.