\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}

Test1

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 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, 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.
% 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.
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{MusiQ Design and Implementation}

In this chapter we describe the design and implementation of our extension.
We start with our design goals, followed high-level overview of the design and a more detailed description of the design and implementation.

\subsection{Design Goals}
First and foremost, our extension should be easyly deployable and backwards compatible to existing QUIC implementations.
To this end, we try to make minimal changes to the protocol and reuse as much of the existing protocol as possible.
Our extension does not change the byte-stream service model that QUIC already provides and produces QUIC packets that are indistinguishable from regular QUIC packets.
With the growing adaption of QUIC, it can therefore easyly be deployed in existing networks.
Furthermore, we want to introduce the message-oriented service model, which is more suitable for real-time communication.
Finally, we want to provide a configurable reliability service, which can be configured to be reliable, partially reliable or unreliable.

\subsection{High-Level Overview of Message Service}
MusiQ adds the message service via a new entity called channel.
A channel is a unidirectional stream that carries messages.
Messages are identified by an offset, which is similar to the offset of data streams.
The application creates messages by writing to a channel.
Every write access to a channel is queued internally and the protocol tries to send the queued messages in order.
The protocol can fragment messages into multiple pieces, called fragments.
Fragments are sent in QUIC packets, which are indistinguishable from regular QUIC packets by an network oberver.
Hence, if a network supports QUIC, it also supports our extension.

\subsection{Fragments}
Fragments are the smallest unit of data that can be sent over the network.
Fragments reuse the structure of a QUIC STREAM frame, but use three bits in the type field to signal that this frame:
\begin{enumerate}
    \item is a fragment
    \item contains with the start of a message
    \item contains the end of a message
\end{enumerate}
Position and values of the bits are shown in Figure \ref{fig:fragment-type}.

% \begin{figure}[h]
%     \centering
%     \includegraphics[width=0.5\textwidth]{fragment-type}
%     \caption{Fragment Type}
%     \label{fig:fragment-type}
% \end{figure}
The sender sets the start bit in the first fragment of a message and the end bit in the last fragment of a message.
For messages that fit into a single fragment, the start and end bit are set.
Fragments which are neither the start nor the end of a message have both bits unset.

The receiver can use the start and end bit to identify the start and end of a message.
That, combined with the re-used offset from data streams, allows the receiver to reassemble the message.
If the receiver has received fragments with a set start bit, a set end bit, and according to the offset every byte inbetween, the receiver can reassemble the message and deliver it to the application.

% 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:
