\documentclass[conference]{IEEEtran}

% \usepackage{abdokoma}
\usepackage{geometry}

\usepackage[
    backend=biber,
    style=authoryear-icomp,
    sortlocale=de_DE,
    natbib=true,
    url=false, 
    doi=true,
    eprint=false
]{biblatex}
\usepackage{titling}
\geometry{left=3cm, right=3cm, top=4cm, bottom=3cm}
% \KOMAoptions{parskip=half+}

\input{preamble.tex}
\addbibresource{quic-message.bib}


% ------------------------------------ %
% The Thing                            %
% ------------------------------------ %

\begin{document}

% \maketitle
\makeabstract
% \tableofcontents

% - QUIC: new-ish protocol
% - traditional service model not sufficient for video transmission
% - solution from webrtc: uses many different protocols, problems with concurrent connections

% - target: add new service model to quic, unreliable and minimize HOL within stream
% - solution: simple extension to quic to add message based communication -> Rapid
% - Story: Extend QUIC to new service applicaitions, specifically realtime + unreliable traffic
%     - benefits: one handshake, one connection
%     - single congestion control
\section{Introduction}
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.

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.

% QUIC is a general purpose transport-layer protocol initially developed by Google in 2012.
% QUIC multiplexes application data as Streams into packets via frames.
% These Streams provide a TCP-like reliable, ordered byte-stream transmission to the application.
% % 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.
% 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.
% 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}
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.

\section{Related Work}

\section{RAPID Design and Implementation}

TODO Motivation

To this end, RAPID adds a new type of stream called Channel.
Channels contain messages, bounded data in a format that the application using QUIC understands, rather than the typical byte-stream.
Furthermore, Channels reuse a lot of the semantics from data streams, namely the offset.
Messages are identified by the offset \dots

Messages are in new frames called Fragments.
Fragments share a lot of commonlality with STREAMFRAMES, but use three bits in TYPE header to signal that
\begin{enumerate}
    \item this frame is a Fragment
    \item fragment carries the start of a message
    \item fragment carries the end of a message
\end{enumerate}


\section{Evaluation}

\section{Conclusion and Future Work}

% Bibliography
% \nocite{*}
\printbibliography

% Author list
\makeauthorlist

\end{document}

%%% Local variables:
%%% ispell-local-dictionary: "english"
%%% TeX-master: t
%%% End:
