diff --git a/preamble.tex b/preamble.tex
new file mode 100644
index 0000000..22c88cb
--- /dev/null
+++ b/preamble.tex
@@ -0,0 +1,27 @@
+% Auto-generated preamble
+
+\title{The Title}
+
+\author{Sebastian Rust}
+
+% \date{\formatdate{08}{03}{2023}}
+
+\newcommand{\makeabstract}{%
+  \begin{abstract}
+    The Abstract.
+  \end{abstract}%
+}
+
+\newcommand{\makeauthorlist}{%
+    \vspace{1em}%
+    \parbox[t]{0.5\textwidth}{%
+      \textbf{Sebastian Rust}\\%
+      \texttt{sebastian.rust@tu-darmstadt.de}\\%
+      \texttt{\url{https://kom.tu-darmstadt.de}}\\%
+      \\%
+      TU Darmstadt\\%
+      Communication Department\\%
+      Rundeturmstr. 20\\%
+      64285 Darmstadt\\%
+    }%
+}
diff --git a/quic-message.tex b/quic-message.tex
index d9a4e30..631e940 100644
--- a/quic-message.tex
+++ b/quic-message.tex
@@ -1,8 +1,20 @@
-\documentclass[a4paper,11pt,english,draft,lightcolors]{scrartcl}
+\documentclass[conference]{IEEEtran}
 
-\usepackage{abdokoma}
+% \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+}
+% \KOMAoptions{parskip=half+}
 
 \input{preamble.tex}
 \addbibresource{quic-message.bib}
@@ -14,14 +26,73 @@
 
 \begin{document}
 
-\maketitle
+% \maketitle
 \makeabstract
-\tableofcontents
+% \tableofcontents
 
-% Blah, blah.
+% - 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}
+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{*}
+% \nocite{*}
 \printbibliography
 
 % Author list