Rapport.tex

\documentclass{article}

% Pour utiliser toues les fonctions du clavier
\usepackage[utf8]{inputenc} % un package
\usepackage[T1]{fontenc}      % un second package

% Choix de la langue
\usepackage[francais]{babel}  % un troisième package
\setlength{\parindent}{0pt}

% Taille des marges
\usepackage[top=2.5cm, bottom=2cm, left=2.5cm, right=1.5cm]{geometry}

% Pour l'espace entre les lignes
\usepackage{setspace}
% Utilisation:
% Moyen:
% \begin{onehalfspace}
% \end{onehalfspace}
% Grand:
% \begin{doublespace}
% \end{doublespace}

% Changement des polices
\usepackage{charter}

% Pour afficher du code
\usepackage{verbatim}
\usepackage{moreverb}


\usepackage{titling}
\setlength{\droptitle}{-5em}   % This is your set screw

% Version 2
\usepackage{listings}

% Couleurs
\usepackage{color}
\usepackage[dvipsnames]{xcolor}
\usepackage{colortbl}

\title{Rapport Labo 3}
\author{\bsc{Bulloni} Lucas \& \bsc{Wermeille} Bastien}
%\date{10 Novembre 2017}

% En-têtes et pieds de pages
\usepackage{fancyhdr}
 
\pagestyle{fancy}
\fancyhf{}
\rhead{\bsc{Bulloni} Lucas \& \bsc{Wermeille} Bastien}
\lhead{Réseau et application.bib}
\chead{Rapport Labo 2}
\cfoot{\thepage}

% Package pour la légende de la table
\usepackage{caption}

% Package de multi-colonnes
\usepackage{multicol}

% Package pour les images
\usepackage{graphicx}

%bibliographie
\usepackage{csquotes}


% Pour les listes
\usepackage{enumitem}
\setlist[itemize]{topsep=0pt,after=\newline}

% package pour liens hypertexte
\usepackage{hyperref}

\definecolor{dkgreen}{rgb}{0,0.6,0}
\definecolor{gray}{rgb}{0.5,0.5,0.5}
\definecolor{mauve}{rgb}{0.58,0,0.82}

\lstset{frame=tb,
	language=Python,
	aboveskip=3mm,
	belowskip=3mm,
	showstringspaces=false,
	columns=flexible,
	basicstyle={\small\ttfamily},
	numbers=none,
	numberstyle=\tiny\color{gray},
	keywordstyle=\color{blue},
	commentstyle=\color{dkgreen},
	stringstyle=\color{mauve},
	breaklines=true,
	breakatwhitespace=true,
	tabsize=3
}

\usepackage[backend=biber]{biblatex}
\addbibresource{biblio.bib}

%\bibliographystyle{plain}
\bibliography{biblio}

% Début du document
\begin{document}

\maketitle

\section{Introduction}
Le but de ce travail pratique est la découverte de techniques permettant de réaliser de la "Quality of Service" (QoS) sur un réseau simple. Ainsi que de tester ces dernières dans un environnement Netkit.

\subsection{Matériel et logiciel à disposition}
\begin{itemize}
	\item Un PC Linux avec NetKit
	\item Laboratoire netkit "qos"
\end{itemize}

\section{Méthodologie}

\subsection{Cas concret}
Grâce au fichier lab.conf, nous pouvons déterminer la structure de réseau suivante:
\begin{figure}[h]
  \centering
  \includegraphics{./Structure.png}
  \caption{Structure du labo netkit}
  \label{fig:structure}
\end{figure}

Le démarrage du laboratoire NetKit "qos" nous permet d'accéder aux 4 périphériques précédemment décrits:
\begin{itemize}
	\item PC
	\item Routeur Entreprise
	\item Routeur FAI
	\item Serveur Internet
\end{itemize}

%\begin{figure}[h]
%  \centering
%  \includegraphics[width=\linewidth]{./captures/1-start.png}
%  \caption{Démarrage du labo netkit "QoS"}
%  \label{fig:qos}
%\end{figure}

\newpage
Une fois le laboratoire démarré, nous pouvons consulter le fichier routeurfai.startup :
\begin{figure}[h]
  \centering
  \includegraphics[width=\linewidth]{./captures/2-RouteurfaiStartup.png}
  \caption{Fichier de configuration "routeurfai.startup"}
  \label{fig:token-bucket}
\end{figure}

Ce fichier contient deux commandes qui mettent en place un tocken bucket sur chaque interface:
\begin{itemize}
\item \textit{tc qdist add dev eth0 root tbf rate 500kbit latency 80ms burst 1540}
\item \textit{tc qdist add dev eth1 root tbf rate 5000kbit latency 80ms burst 15400}
\end{itemize}

Grâce à la commande "tcqdisc list", nous pouvons constater que ces deux commandes ont bien fonctionné:
\begin{figure}[h]
  \centering
  \includegraphics[width=\linewidth]{./captures/3-TokenBucket.png}
  \caption{Configurations Token Bucket}
  \label{fig:token-bucket}
\end{figure}

Le tocken bucket prend notamment deux paramètres principaux, rate et latency, voici à quoi ils correspondent en comparaison avec le modèle du baquet:
\begin{itemize}
\item rate -> débit standard ou constant, paramètre de la vitesse
\item latency -> taille du baquet, nombre d’octets qui peut être mis en file d’attente en attendant la disponibilité de jetons
\end{itemize}

La configuration actuelle nous permet d'accéder à serveurinternet:
\begin{figure}[h]
  \centering
  \includegraphics[width=\linewidth]{./captures/4-ping.png}
  \caption{Ping serveurinternet}
  \label{fig:token-bucket}
\end{figure}
\newpage

L'étape suivante a été d'évaluer les performances:

\begin{tabular}{|l|c|}
  \hline
   & Débit [Ko/s]\\
  \hline
  Débit montant & 49 \\
  Débit descendant & 580 \\
  \hline
\end{tabular}
\\

\begin{figure}[h]
	\centering
	\includegraphics[width=\linewidth]{./captures/debit-descendant.png}
	\caption{Débit montant et descendant}
	\label{fig:token-bucket}
\end{figure}

ainsi que les pings:

\begin{tabular}{|l|c|}
  \hline
   & Temps [ms]\\
  \hline
  A vide & 1.19 \\
  avec débit descendant & 75 \\
  avec débit montant & 100 \\
  \hline
\end{tabular}


\begin{figure}[h]
	\centering
	\includegraphics{./captures/pingdescendant.png}
	\caption{Ping descendant}
	\label{fig:token-bucket}
\end{figure}


\begin{figure}[h]
	\centering
	\includegraphics{./captures/pingmontant.png}
	\caption{Ping montant}
	\label{fig:token-bucket}
\end{figure}





\subsubsection{Questions sur cette partie}
\textbf{a) Est-ce que les performances, chaque sens pris séparément, correspondent à celle prévue ?}\\
Oui, ce n'est pas exactement les mêmes valeurs, mais c'est très proche du résultat attendu.
\\

\textbf{b) si vous faites des transferts dans les deux sens, qu'observez-vous au niveau des débits ?}\\
Nous avons effectué un test en mesurant le débit dans les deux directions en même temps:\\
\begin{tabular}{|l|c|}
  \hline
   & Débit [Ko/s]\\
  \hline
  Débit montant & 45 \\
  Débit Descendant & 516 \\
  \hline
\end{tabular}
\\

On constate que les deux débits sont plus petits que ceux mesurés indépendamment, cela s'explique par le fait que chaque message reçu dans un sens nécessite une confirmation qui va prendre du débit dans le sens opposé.
\\

\textbf{c) Qu'observez-vous si vous faites des ping simultanément à des transferts ?}\\
La vitesse des transferts diminue, car les pings prennent du débit au transfert. Les pings ont un délai plus long à cause de l'augmentation de trafic.

\subsubsection{Partie spécifique au rapport}
Grâce au script, nous avons généré le graph de latence, une fois sans trafic:
\begin{figure}[h]
  \centering
  \includegraphics[width=\linewidth]{./captures/6-plot.png}
  \caption{Graph avec trafic à vide}
  \label{fig:token-bucket}
\end{figure}
\newpage

Puis la seconde fois avec du trafic full-duplex afin de négliger la latence du réseau losrqu'il n'y a pas de trafic et que la variance varie beaucoup en très peu de temps:
\begin{figure}[h]
  \centering
  \includegraphics[width=\linewidth]{./captures/6-plot-fullduplex.png}
  \caption{Graph avec trafic full-duplex}
  \label{fig:token-bucket}
\end{figure}
\newpage

Nous avons également simulé des flux udp et effectué un ping visible ci-dessous:\\

\begin{figure}[h]
  \centering
  \includegraphics[width=\linewidth]{./captures/10-udp.png}
  \caption{ping durant trafic upd}
  \label{fig:token-bucket}
\end{figure}
\newpage

\subsection{Traffic Shaping Simple}
Nous allons limiter le débit montant sur routeurentreprise en appliquant une queue TBF sur l'interface sortante grâce à un très faible délai de stockage.
\begin{figure}[h]
  \centering
  \includegraphics[width=\linewidth]{./captures/11-limite.png}
  \caption{Limitation trafic montant routeurentreprise}
  \label{fig:token-bucket}
\end{figure}

En mesurant les délais, on a pu tester et montrer que les délais mesurés sont meilleurs en présence de trafic TCP montant, avec cette limitation:
\\

\textbf{Montrer dans quelle mesure le trafic d'information TCP est ralenti par cette limite et expliquer pourquoi}\\
Le débit est plus petit. Lors de l'envoi de paquets, beaucoup de ceux-ci vont déborder du baquet, ce qui va nécessiter le réenvoie des paquets jetés par le système. Ces pertes vont ralentir le système tout entier.

Les statistiques de queue obtenues lors de notre test sont les suivantes:
\begin{figure}[h]
  \centering
  \includegraphics[width=\linewidth]{./captures/13-stat-queue.png}
  \caption{Limitation trafic montant routeurentreprise}
  \label{fig:token-bucket}
\end{figure}

\subsection{Marquage du trafic classifié}

Comme précisé dans la donnée, lorsqu'on crée deux flux TCP vers serveurinternet, les deux débits sont environ identiques. La suite de l'exercice consistait à différencier les deux flux en marquant des paquets avec le bit TOS en fonction du port de destination.\\

Le bit TOS peut être marqué directement depuis les applications ou depuis le firewall. Pour cette partie nous l'avons fait avec le firewall.\\

La commande pour indiquer au routeur de marquer les bits à destination du port 7002 avec le TOS est celle-ci :\\

iptables -I OUTPUT -t mangle -p tcp --dport 7002 -j TOS --set-tos Minimize-Delay\\

On peut ensuite voir que le trafic a bien été marqué sur la prise d'écran ci-dessous : 

\begin{figure}[h]
  \centering
  \includegraphics[width=\linewidth]{./captures/tos-Flag.png}
  \caption{flag TOS}
  \label{fig:token-bucket}
\end{figure}


\subsection{Classification et traffic shaping hiérarchique}

Il est également possible de faire de la qualité de service en faisant une hiérarchie de priorisation pour avoir une plus grande liberté et complexité. Aussi appelé "Hierarchical Token Buffer" ou HTB. \\

Ensuite l'exercice consistait à implémenter un HTB comme celui-ci : \\

\begin{itemize}
	\item 3/4 du débit pour les paquets à destination du port TCP 7001
	\item 1/4 composé de : 
	\subitem 3/4 du débit restant pour tout le contenu autre que 7001 et 7002
	\subitem 1/4 du débit restant pour les paquets à destination du port TCP 7002
\end{itemize}

Donc un arbre à 2 niveaux représenté comme cela :

\begin{figure}[h]
	\centering
	\includegraphics{./arbre-htb.png}
	\caption{Arbre HTB}
	\label{fig:htb-tree}
\end{figure}
\newpage

Les instructions pour créer cette HTB étaient données dans le cours à la page 56 \cite{doc-labo}. \\

Les tests peuvent être observés sur les prises d'écran ci-dessous : 

\begin{figure}[h]
	\centering
	\includegraphics{./captures/htb1.png}
	\caption{Arbre HTB}
	\label{fig:Débit port 7001}
\end{figure}
\begin{figure}[h]
	\centering
	\includegraphics{./captures/htb2.png}
	\caption{Arbre HTB}
	\label{fig:Débit port 7002}
\end{figure}
\begin{figure}[h]
	\centering
	\includegraphics{./captures/htb3.png}
	\caption{Arbre HTB}
	\label{fig:Débit port 7003}
\end{figure}
\newpage

S'il on fait le calcule, on peut remarquer que le débit est assez proche du résultat attendu. \\

Débit total : 55 K/s\\
Port 7001 : théorique - 41.125 K/s, pratique 41 K/s\\
Port 7002 : théorique - 3.4 K/s, pratique 6 K/s\\
Port quelconque : théorique 10.25 K/s, pratique 10 K/s

\subsubsection{WonderShaper}

Le script a 3 buts principaux : \\

\begin{itemize}
	\item améliorer au maximum possible la latence afin que des protocoles comme SSH ou Telnet ne soient pas perturbés par le reste du trafic.
	\item garder un débit correct en HTTP tout en ayant un trafic fort en débit montant et descendant
	\item Limiter l'impacte du débit montant sur le débit descendant et l'inverse y compris
\end{itemize}

Et le script contient un certain nombre de règles pour le routeur afin de créer des classes et des Stochastic Fair Queue pour faire de la priorisation de service pour certains ports.

\section{Questions de base}

\subsection*{1 : Expliquer en quelques mots le principe de l'algorithme de régulation TCP}

Certains routeurs vont marquer les paquets lorsqu'ils s'apprêtent à subir une congestion, ce système s'appelle l'ECN (Explicit Congestion Notification). Mais ce système mise sur le fait que les d'autres routeurs implémentent ce système. \cite{cours}\\

Les paquets marqués vont indiquer au client qu'il doit diminuer son débit.

\subsection*{2 : Pourquoi un MTU plus faible peut améliorer la QoS?}

Un MTU plus faible va baisser l'efficacité de la communication, mais va améliorer le temps de réponse.
\begin{enumerate}
\item Problème de partage des trames
\item Guigge de phase très variable
\item Baisse de l'efficacité, mais diminue le temps de réponse
\end{enumerate}

\subsection*{3 : Que doit faire un opérateur lorsqu'il remarque des bits TOS et DIFFSERV activés avec un débit ne correspondant pas au SLA ?}

Lorsqu'un opérateur remarque des bits TOS \cite{ToS} et DIFFSERV \cite{DiffServ} chez un client qui n'a pas de qualité de service dans sa prestation veut dire qu'il essaye de tricher.\\

L'opérateur peut alors faire 2 choses différentes selon sa politique envers les clients qui essayent de tricher : 

\begin{itemize}
 	\item Jeter tous les paquets
 	\item Ignorer ces bits et les supprimer de tous les paquets
\end{itemize}

\subsection*{4 : Comment diminuer la vitesse du sens descendant en modifiant celle du sens montant?}

Il y a deux possibilités. La première est de réduire la vitesse du débit montant de cette connexion, ce qui aura pour effet d'également réduire la vitesse du sens descendant, car les paquets de confirmation mettront plus de temps à atteindre leur destination et ainsi les messages suivants seront retardés.\\

La deuxième solution est de supprimer des paquets de confirmations. L'émetteur attendra alors jusqu'au timeout et devra réémettre les paquets dans la confirmation n'au pas été reçue. La fenêtre passera également moins rapidement aux paquets suivants puisque certains paquets n'auront pas été confirmés ce qui va ralentir le débit descendant.

\subsection*{5 : Le sens montant est saturé, comment assurer un bon débit descendant}

Il serait possible de grouper les confirmations (ACK) comme le fait go back-n\cite{GoBackN} ou alors, en faisant de la QoS et en priorisant les messages de confirmation (ACK).\\

Si on priorise ces messages, alors ceux-ci passeront plus facilement outre la saturation et le débit descendant souffrira moins de la saturation du sens montant.


\subsection*{6 : Pourquoi gérer le traffic shaping seulement sur routeurentreprise produit de bon résultat, mais n'est toujours pas suffisant?}

La première raison est que routeurentreprise ne peut gérer que le trafic propre à son sous-réseau et non le trafic de tous les clients connectés au routeur du FAI. Le routeur FAI aura donc un trafic beaucoup plus important et la QoS sera donc plus utile sur cette partie du réseau.\\

Mais le faire sur le routeur de l'entreprise permet déjà d'avoir une priorisation par rapport au trafic de l'entreprise et donc d'avoir un résultat qui peut-être satisfaisant si le routeur FAI subit très peu de congestion.

Dans le cas ou le routeur FAI est saturé alors la priorisation du côté de routeurentreprise ne sera pas suffisante, car une autre sélection sera effectuée du côté du routeurFAI.

\subsection*{7 : Quelle queue est recommandée pour garantir un traitement équitable des données? Est-ce que le Token Bucket répond à ces besoins ?}

Une queue de type SFQ \cite{SFQ} est recommandée pour garantir un traitement plus équitable des données.\\

Un baquet ne serait pas adapté, car ce système se contente de supprimer les paquets qu'il reçoit lorsqu'il est en surcharge \cite{Bucket}


\section{Questions rapport}

\subsection*{1 : Qu'est-ce que le routage de la patate chaude et à quoi sert-il dans un réseau surchargé?}

C'est un système de routage où les paquets vont être envoyés sans être stocké en mémoire et sans vérifier par quel chemin ils seront le mieux acheminer. \cite{HotPotato}

\subsection*{2 : Avec quel outil peut-on évaluer le nombre de paquets reçus en désordre?}

Il est possible d'évaluer le nombre de paquets reçu en désordre avec Wireshark.


\subsection*{3 : Proposer une répartition de débit entre classes plus logique dans un réseau réel}

Si on priorise le TCP, les paquets devant crucialement être acheminés seront priorisés et les paquets UDP vont soit être perdus ou en retard. \\

Mais vu que les protocoles utilisant UTP ne requièrent pas un taux de réception de 100\%. 

\subsection*{4 : Conception d'un baquet}

Tous les snippets de code sont également présents dans l'annexe 'TokenBucket.py'

\subsubsection{Classe représentant un baquet}

\paragraph{enqueue}

Le baquet utilise une queue où l'on va définir une taille maximum de message en attente d'être envoyé. Lorsqu'on essaye d'ajouter un message à envoyer, le baquet va regarder le nombre de messages en attente et si ce nombre est égal au nombre de messages maximum, le message va être jeté.\\

Autrement le message va être ajouté dans la queue en attendant d'être envoyé qu'il soit envoyé.

\paragraph{dequeue}

La fonction de dequeue va essayer de pop le futur message à envoyer et lorsque la queue est vide une erreur va être levée.

\paragraph{printSize}

La fonction printSize n'a pas de réelle utilité si ce n'est d'afficher des informations sur le l'état du baquet (message en attente / taille maximale) dans le code d'utilisation du baquet

\paragraph{code}

Voici le code du baquet : 

\begin{lstlisting}
class TokenBucket(object):
	def __init__(self, burstLimit):
		self.burstLimit = burstLimit
		self.messages = deque([])
	
	def enqueue(self, message):
		if len(self.messages) == self.burstLimit:
			return None
		else:
			self.messages.append(message)
		return message
	
	def dequeue(self):
		try:
			val = self.messages.pop()
		except IndexError:
			val = None
		
		return val
	
	def printSize(self):
		print(str(len(self.messages)) + '/' + str(self.burstLimit) + ' messages')
\end{lstlisting}

\subsubsection{Code d'utilisation du baquet}

Pour simuler l'utilisation d'un baquet, on va tirer un nombre aléatoire entre 0 et 1 et si ce nombre est plus grand que 0.2 on va mettre un message dans le baquet, sinon on va lire le message.\\

Ensuite on va attendre 0.5 seconde afin qu'on puisse voir ce qu'il se passe.

\begin{lstlisting}
if __name__ == '__main__':
	bucket = TokenBucket(10)
	
	while True:
		qorDeQ = random.random()
		
		if qorDeQ > 0.2 :
			val = bucket.enqueue(random.randint(0,100))
			print('queue message')
			
			if val != None:
				bucket.printSize()
			else:
				print('bucket is full')
		
		else :
			print('dequeue message')
			val = bucket.dequeue()
		
			if val == None:
				print('Bucket is empty')
			else:
				bucket.printSize()
	
		time.sleep(0.5)
\end{lstlisting}

\section{Conclusion}
Le but de ce laboratoire était de découvrir la QoS au sein de réseau et mettre en place des solutions simples existantes.
\\

Ce laboratoire s'est déroulé sans problème particulier, toutes les parties à prouver ont été réalisées. Nous avons pu mettre en place et tester plusieurs solutions de QoS, tels que le flag TOS et/ou encore les tables hiérarchiques HTB. Toutes les questions ont été répondues et un code simple en python permettant d'illustrer le fonctionnement d'un baquet a été réalisé.
\\

Malgré nos faibles connaissances dans le domaine de la QoS, il a été très intéressant de faire ce laboratoire afin de découvrir à quel point ces technologies ont un réel impact sur les réseaux que nous utilisons dans la vie de tous les jours.

\printbibliography


\end{document}