added: build workflow

.gitea/workflows/build.yml

@@ -0,0 +1,21 @@
+name: latex build
+run-name: ${{ gitea.actor }} is testing out Gitea Actions 🚀
+on: [push]
+
+jobs:
+  Explore-Gitea-Actions:
+    runs-on: docker
+    container:
+        image: leplusorg/latex
+    steps:
+        - run: echo "🎉 The job was automatically triggered by a ${{ gitea.event_name }} event."
+        - run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by Gitea!"
+        - run: echo "🔎 The name of your branch is ${{ gitea.ref }} and your repository is ${{ gitea.repository }}."
+        - name: Check out repository code
+          uses: actions/checkout@v3
+        - run: echo "💡 The ${{ gitea.repository }} repository has been cloned to the runner."
+        - run: make pdf
+        - uses: actions/upload-artifact@v3
+          with:
+            path: quic-message.pdf
+            name: main.pdf

.gitea/workflows/demo.yml

@@ -1,19 +0,0 @@
-name: Gitea Actions Demo
-run-name: ${{ gitea.actor }} is testing out Gitea Actions 🚀
-on: [push]
-
-jobs:
-  Explore-Gitea-Actions:
-    runs-on: ubuntu-latest
-    steps:
-      - run: echo "🎉 The job was automatically triggered by a ${{ gitea.event_name }} event."
-      - run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by Gitea!"
-      - run: echo "🔎 The name of your branch is ${{ gitea.ref }} and your repository is ${{ gitea.repository }}."
-      - name: Check out repository code
-        uses: actions/checkout@v3
-      - run: echo "💡 The ${{ gitea.repository }} repository has been cloned to the runner."
-      - run: echo "🖥️ The workflow is now ready to test your code on the runner."
-      - name: List files in the repository
-        run: |
-          ls ${{ gitea.workspace }}
-      - run: echo "🍏 This job's status is ${{ job.status }}."

Makefile

@@ -99,7 +99,7 @@ write-if-changed-cmd = if [ ! -f "$2" ] || [ ! "$1" = "`cat $2 2> /dev/null`" ];
 #----------------------------------#
 
 # shell settings
-SHELL       := /usr/bin/bash
+SHELL       := bash
 .SHELLFLAGS := -e -u -c
 
 # Use a single shell

quic-message.tex

@@ -140,24 +140,65 @@ Furthermore, it provides a configurable reliability service, which can be config
 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.
 
-\section{RAPID 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.
 
-TODO Motivation
+\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.
 
-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
+\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 this frame is a Fragment
-    \item fragment carries the start of a message
-    \item fragment carries the end of a message
+    \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}