leo/Rapport_stage_M1
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Merge branch 'correction'

Browse source
This commit is contained in:
Leopold Clement 2021-08-21 11:18:30 +02:00
commit 8a5d7bcdd2
1 changed files with 109 additions and 109 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

218
rapport.tex
View file

@ -1,4 +1,4 @@
% !TEX encoding = UTF-8 Unicode
% !TEX encoding = UTF-8 Unicode
% -*- coding: UTF-8; -*-
% vim: set fenc=utf-8
\documentclass[a4paper,12pt,french]{article}
@ -37,7 +37,7 @@
\newglossaryentry{tcp}
{
name=TCP,
description={Transmission Control Protocol, protocol avancé de la couche \osi{} 4}
description={Transmission Control Protocol, protocole avancé de la couche \osi{} 4}
}
\newcommand{\tcp}{\gls{tcp}}
@ -45,7 +45,7 @@
\newglossaryentry{udp}
{
name=UDP,
description={User Datagram Protocol, protocol basique de la couche \osi{} 4}
description={User Datagram Protocol, protocole basique de la couche \osi{} 4}
}
\newcommand{\udp}{\gls{udp}}
@ -53,7 +53,7 @@
\newglossaryentry{coap}
{
name=CoAP,
description={Constrained Application Protocol, protocol de la couche \osi{} 7}
description={Constrained Application Protocol, protocole de la couche \osi{} 7}
}
\newcommand{\coap}{\gls{coap}}
@ -61,7 +61,7 @@
\newglossaryentry{cocoa}
{
name=Cocoa+,
description={Evolution de \coap{}, protocol de la couche \osi{} 7}
description={Evolution de \coap{}, protocole de la couche \osi{} 7}
}
\newcommand{\cocoa}{\gls{cocoa}}
@ -77,7 +77,7 @@
\newglossaryentry{keras}
{
name=keras,
description={Module Python pour la manipulation de réseaux de neurrones}
description={Module Python pour la manipulation de réseaux de neurones}
}
\newcommand{\keras}{\gls{keras}}
@ -125,7 +125,7 @@
\newglossaryentry{cc}
{
name=CC,
description={Controle de congestion}
description={Contrôle de congestion}
}
\newcommand{\CC}{\gls{cc}}
@ -133,7 +133,7 @@
\newglossaryentry{cca}
{
name=CCA,
description={Algoritme de controle de congestion}
description={Algorithme de contrôle de congestion}
}
\newcommand{\CCA}{\gls{cca}}
@ -141,7 +141,7 @@
\newglossaryentry{mac}
{
name=MAC,
description={Media Access Control, Controle de l'access à médium de communication}
description={Media Access Control, Contrôle de l'accès à médium de communication}
}
\newcommand{\mac}{\gls{mac}}
@ -157,7 +157,7 @@
\newglossaryentry{http}
{
name=HTTP,
description={Hypertext Transfer Protocol, protocol de la couche \osi{} 7}
description={Hypertext Transfer Protocol, protocole de la couche \osi{} 7}
}
\newcommand{\http}{\gls{http}}
@ -171,7 +171,7 @@
\newglossaryentry{rtt}
{
name=RTT,
description={Round Trip Time, temps d'aller retour}
description={Round Trip Time, temps d'aller-retour}
}
\newcommand{\rtt}{\gls{rtt}}
@ -247,18 +247,18 @@
\subsection{Qu'est-ce qu'un réseau \iot{} ?}
Un réseau \iot{} est un réseau de machine informatique embarqué.
Les machines qui composent ce réseau sont en majorité des machines peut puissante : des capteurs, des actionneurs \dots, ils réalisent chacun une tache simple, et sont soumis à de multiple contrainte, en particulier sur la consomation energetique.
Les réseaux \iot{} présentent donc des thématiques propres au réseaux classique (débit, latence, pertes de données \dots), qui ont déjà été étudier par le passé et où des solutions éxisent, et des thématique nouvelles qui ne n'intégre pas dans le modèle classique.
Un réseau \iot{} est un réseau de machines informatiques embarquées.
Les machines qui composent ce réseau sont en majorité des machines peu puissantes : des capteurs, des actionneurs \dots, ils réalisent chacun une tâche simple, et sont soumis à de multiples contraintes, en particulier en termes de consommation énergétique.
Les réseaux \iot{} présentent donc des thématiques propres aux réseaux classiques (débit, latence, pertes de données \dots), qui ont déjà été étudiées par le passé pour lesquelles des solutions exisent, et des thématique nouvelles qui ne s'intègrent pas dans le modèle classique.
\subsubsection{Qu'est-ce qu'un réseau ?}
Un réseau informatique est un groupe de machines indépendantes que l'ont connecte entre elles pour qu'elles echange des informations.
Ces connexion se font au travers de normes et de protocoles, qui sont organisé dans un modèle à $7$ couches, le modèle \osi{}:
Un réseau informatique est un groupe de machines indépendantes que l'on connecte entre elles pour qu'elles échangent des informations.
Ces connexions se font au moyen de normes et de protocoles organisés dans un modèle à $7$ couches, le modèle \osi{}:
\begin{table}[htp]
\centering
\caption[modèle \osi{} général]{Le modèle \osi{} pour internet, les couches principales.}
\caption[modèle \osi{} général]{Le modèle \osi{} pour Internet, les couches principales.}
\begin{tabular}{lll}
\toprule
Couche & Rôle & Protocole\\
@ -266,94 +266,94 @@ Ces connexion se font au travers de normes et de protocoles, qui sont organisé
7 - Application & Utilisation finale & http, ssh...\\
4 - Transport & \CC{} \& multiplexage & \tcp{}, \udp{}\\
3 - Réseau & Routage & IP\\
1 \& 2 - Physique & Support des communications & Ethernet, WiFi...\\
1 \& 2 - Physique & Support des communications & Ethernet, Wi-Fi...\\
\bottomrule
\end{tabular}
\end{table}
Les couches $1$ et $2$ permetent de communiqué entre deux machines directement reliées.
C'est ici qu'intervien l'adresse \mac{}.
La couches $3$ décrit le routage pour passer par des machines intermediaire afin de voyagé dans l'ensemble du réseaux.
C'est ici qu'intervien l'adresse \ip{}.
La couches $4$ décrit les protocoles permetant d'établire un connexion entre deux application sur les machines hotes.
Cela inclue donc le multiplexage des données (c'est le port sur la machines hotes), ainsi que la gestion de la congestion.
Les couches $5$ et $6$ n'ont pas d'influance sur la suite, et sont donc négligé.
Elles permetent par exemple d'encrypté la connexion avec le \emph{SSL}.
La couche $7$ est la couche applicative, c'est à dire l'utilisations final que l'ont fait de la connexion.
Cela peut etre chargé une page inernet, lire ses mails, regarder une vidéo, ou bien, transmetre des mesures d'un capteur.
C'est cette dernière utilisation qui nous interresse ici.
Les couches $1$ et $2$ permettent la communication entre deux machines directement reliées.
C'est ici qu'intervient l'adresse \mac{}.
La couches $3$ décrit le routage pour passer par des machines intermédiaires afin de voyager dans l'ensemble du réseau.
C'est ici qu'intervient l'adresse \ip{}.
La couches $4$ décrit les protocoles permettant d'établir une connexion entre deux applications sur les machines hôtes.
Cela inclut donc le multiplexage des données (c'est le port sur la machine hôte), ainsi que la gestion de la congestion.
Les couches $5$ et $6$ n'ont pas d'influence sur la suite, et sont donc négligées.
Elles permettent par exemple d'encrypter la connexion avec le \emph{SSL}.
La couche $7$ est la couche applicative, c'est-à-dire l'utilisation finale que l'on fait de la connexion.
Il peut s'agir de charger une page Internet, lire ses mails, regarder une vidéo, ou bien transmetre les mesures d'un capteur.
C'est cette dernière utilisation qui nous intéresse ici.
La qualité d'une connexion entre deux points peut etre évalué grace à deux valeurs : \begin{itemize}
\item Le delai, qui correspont à la durée écoulé entre le moment où l'application émétrice veux emmetre le message, et le moment où le message est reçu par l'application cliente.
\item Le débit, qui correspont à la quantité de bits pouvant etre envoyé par seconde entre les deux applications.
La qualité d'une connexion entre deux points peut être évaluée grâce à deux valeurs : \begin{itemize}
\item Le délai, qui correspond à la durée écoulée entre le moment où l'application émettrice veut émettre le message, et le moment où le message est reçu par l'application cliente.
\item Le débit, qui correspond à la quantité de bits pouvant être envoyés chaque seconde entre les deux applications.
\end{itemize}
Ces deux grandeur n'ont pas la même importance selon l'application.
Par exemple, pour envoyé un piece jointe dans un mail, le delai n'est pas très important, c'est le débit qui compte pour que la transactio ne soit pas trop longue.
Mais pour un jeu en ligne, il y a peu de donné à echangée, mais il faut le faire avec le moins de délai possible pour que le jeu reste fluide.
Suivant l'application, il faut favorisé l'un ou l'autre, ou trouver un compromis satifaisant.
Ces deux grandeurs n'ont pas la même importance selon l'application.
Par exemple, pour envoyer une pièce jointe dans un mail, le délai n'est pas très important : c'est le débit qui compte pour que la transaction ne soit pas trop longue.
Par contre, dans le cas d'un jeu en ligne il y a peu de données à echanger mais il faut le faire avec le moins de délai possible pour que le jeu reste fluide.
Suivant l'application, il faut favoriser l'un ou l'autre, ou trouver un compromis satifaisant.
\subsubsection{Qu'est-ce que la congestion ?}
Malheureusment, les reseaux étant hétérogène, on ne controle pas tout les parrametres lorsque on les utilise.
En effet, pour envoyé un paquet à une autre machines, il faut (dans le cas général) passer par plusieurs intermediaire, les routeurs.
Lesdit routeurs ne doivent pas géré que un seul flux, et tout les liens entre les routeurs n'ont pas la même capacité, ainsi on se retrove avec des accumulaions de paquet dans certain routeur.
L'accumulations se produit au niveau des goulots d'étranglements.
Les routeurs n'ont pas une mémoire infini, ils ne peuvent donc pas laisser les queues d'envoie grandir à l'infini.
Elles ont donc une taille limite, et il faut donc parfois ne pas traité certain paquet lorsque le réseau est trop chargé.
Ce phénoméne est la congestion.
On cherche à l'évité, car un paquet non-traité est un paquet perdu, et donc le message n'est pas complet pour le client.
La gestion de la congestion sera expliqué avec plus de détail dans la partie \ref{part_cc}.
La detection de la congestion se fait souvent à l'aide d'un accusé de réception : si l'accusé n'est pas reçu au bout d'un certain temps, on considère le message perdu.
Lorsque des paquets sont perdu à cause de la congestion, il faut les réenvoyé, en faisant attention de ne pas recongestioner le réseau.
Une grande partie des optimisations du \CC à lieu au niveau de ce temps d'attente, le \rto.
Malheureusement, les réseaux étant hétérogènes, on ne contrôle pas tout les paramètres lorsqu'on les utilise.
En effet, pour envoyer un paquet à une autre machine, il faut (dans le cas général) passer par plusieurs intermédiaires, les routeurs.
Lesdits routeurs ne doivent pas gérer qu'un seul flux, et tous les liens entre les routeurs n'ont pas la même capacité ; ainsi on se retrouve avec des accumulations de paquets dans certains routeurs.
L'accumulation se produit au niveau des goulots d'étranglement.
Les routeurs n'ont pas une mémoire infinie, ils ne peuvent donc pas laisser les queues d'envoi grandir à l'infini.
Elles ont donc une taille limite, et il faut donc parfois ne pas traiter certains paquets lorsque le réseau est trop chargé.
Ce phénomène est appelé congestion.
On cherche à l'éviter, car un paquet non traité est un paquet perdu, donc le message n'est pas complet pour le client.
La gestion de la congestion sera expliquée plus en détail dans la partie \ref{part_cc}.
La détection de la congestion se fait souvent à l'aide d'un accusé de réception : si l'accusé n'est pas reçu au bout d'un certain temps, on considère le message comme perdu.
Lorsque des paquets sont perdus à cause de la congestion, il faut les réenvoyer, en faisant attention de ne pas recongestionner le réseau.
Une grande partie des optimisations du \CC a lieu au niveau de ce temps d'attente, le \rto.
\subsubsection{Quelle sont les spécificité des réseaux \iot{} ?}
\subsubsection{Quelles sont les spécificités des réseaux \iot{} ?}
Dans un réseau \iot, les contraintes et applications sont différentes : \begin{itemize}
\item On échange des messages courts,
\item on veux minimisé la consomation energetique des machines,
\item les machines sont peut puissante, et ne peuvent pas réalisé des calcule complexe.
\item on veut minimiser la consommation énergétique des machines,
\item les machines sont peu puissantes, et ne peuvent pas réaliser de calculs complexes.
\end{itemize}
Les technologies employé sont surtout des connexions dans fils à basse consomation, et à bas débit.
On peut cité les technologies
Les technologies employées sont surtout des connexions sans fil à basse consommation, et à bas débit.
On peut citer les technologies %manque référence
De plus, pour accédé aux ressources d'une autre machine, on ne peut pas utilisé l'\http{} comme sur un ordinateur de bureau ou un téléphone.
En effet, \http{} s'appuis sur \tcp{}, et induit donc beaucoup de message supplémentaire.
Ainsi, puisque on echange des petits messages, on se retrouve avec plus d'entête que de contenu dans les couches physique, et donc on consomme beaucoup de ressources pour rien.
Un nouveau protocole a donc été dévolopé pour proposé des fonctionalités similaire à \http{}, mais adapté au contrainte de l'\iot{}, le protocole \coap{}.
De plus, pour accéder aux ressources d'une autre machine, on ne peut pas utiliser l'\http{} comme sur un ordinateur de bureau ou un téléphone.
En effet, \http{} s'appuie sur \tcp{}, et induit donc beaucoup de messages supplémentaires.
Ainsi, puisqu'on échange de petits messages, on se retrouve avec plus d'en-tête que de contenu dans les couches physiques, et on consomme beaucoup de ressources pour rien.
Un nouveau protocole a donc été développé pour proposer des fonctionnalités similaires à \http{}, mais adaptées aux contraintes de l'\iot{}, le protocole \coap{}.
\subsection{Quelle sont les particularités du \coap{} ?}
\subsection{Quelles sont les particularités du \coap{} ?}
\coap{} est un protocole de la couche $7$ de l'\emph{IETF} (Internet Engenering Task Force) offrant une interface similaire à l'\http.
\coap{} est un protocole de la couche $7$ de l'\emph{IETF} (Internet Engineering Task Force) offrant une interface similaire à l'\http.
L'interface en question est une interface \emph{RestFull} :\begin{itemize}
\item Les ressources sont identifiées par des url, par exemple \url{coap://exemple.com/ressource/en/ligne},
\item On peut intéragire avec les ressources au moyen de plusieurs méthodes: \begin{itemize}
\item On peut interagir avec les ressources au moyen de plusieurs méthodes: \begin{itemize}
\item GET : On demande le contenu de la ressource distante,
\item POST, PUT : On crée ou remplace le contenu de la ressource distante,
\item DELETE : on supprime la ressource.
\end{itemize}
\end{itemize}
En plus de ses méthodes qui ont leurs equivalents chez \http{}, il y a la methode OBSERVE.
Si un client demande à observé une ressource sur un serveur, le serveur lui enveré automatiquement la ressource à chaque fois que elle est modifiée.
Les ressources utilisé avec \coap{} ne sont pas les même que en \http{}, on ne cherche pas à transféré une suite de centaine voir millier de paquet, mais un seul.
Mais à la congestion classique se rajoute le risque de perte de paquet à cause des liaisons physique, car les infratructures sans fils sont soumise à de la perte aléatoire.
En plus de ces méthodes, qui ont leur équivalent chez \http{}, il y a la méthode OBSERVE.
Si un client demande à observer une ressource sur un serveur, le serveur lui enverrait automatiquement la ressource à chaque fois qu'elle est modifiée.
Les ressources utilisées avec \coap{} ne sont pas les mêmes qu'en \http{}, on ne cherche pas à transférer une suite de centaines voire de milliers de paquets mais un seul.
A la congestion classique s'ajoute le risque de perte de paquets à cause des liaisons physiques, car les infrastructures sans fil sont soumises à de la perte aléatoire.
D'un point de vu technique, \coap{} a la particularité de reposé sur l'\udp{} et non le \tcp{}.
Ainsi le \CC{} est réalisé par la couche applicative et non la couche transport.
D'un point de vue technique, \coap{} a la particularité de reposer sur l'\udp{} et non sur le \tcp{}.
Ainsi le \CC{} est réalisé par la couche applicative et non par la couche transport.
Lorsque l'on envoie un message, il peut etre de deux type : \begin{itemize}
\item CON : confirmable, on demande un accusé de reception du message,
\item NCON, non-conformable, on ne demande pas d'accusé de reception.
Lorsque l'on envoie un message, il peut être de deux types : \begin{itemize}
\item CON : confirmable, on demande un accusé de réception du message,
\item NCON, non confirmable, on ne demande pas d'accusé de réception.
\end{itemize}
Les messages NCON ne sont donc pas réenvoyé si ils sont perdu à cause de la congestion, car il n'y a pas de moyen de la détecter.
Cela peut ne pas etre un problème pour certaine application.
Il y a aussi les messages de type ACK, qui aquite les message CON.
L'association entre le message CON et ACK se fait grace à un token (ACK[0xe4] aquite le message CON[oxe4]).
Les messages NCON ne sont donc pas réenvoyés s'ils sont perdus à cause de la congestion, car il n'y a pas moyen de la détecter.
Cela peut ne pas être un problème pour certaines applications.
Il y a aussi les messages de type ACK, qui acquittent les messages CON.
L'association entre le message CON et ACK se fait grâce à un token (ACK[0xe4] qui acquitte le message CON[oxe4]).
Ses derniers temps, des nouvelles solutions bassé sur l'apprentissage machine se sont développé pour le \CC{} en \tcp{}.
Notre problèmatique est donc de savoir si de tel solutions sont applicable à \coap{}.
Ces derniers temps, de nouvelles solutions basées sur l'apprentissage machine se sont développées pour le \CC{} en \tcp{}.
Notre problèmatique est donc de savoir si de telles solutions sont applicables à \coap{}.
\subsection{Qu'est-ce que l'apprentissage par renforcement ?}
@ -363,72 +363,72 @@ Notre problèmatique est donc de savoir si de tel solutions sont applicable à \
\caption{Exemple de processus Markovien à trois états et deux actions.}
\end{wrapfigure}
L'apprentissage par renforcement est une solution d'apprentissage machine pour les systèmes markoviens.
L'apprentissage par renforcement est une solution d'apprentissage machine pour les processus markoviens.
Le système est constitué d'un environnement et d'un acteur.
On suppose que le temps est discontinu.
Ainsi à l'instant $t$, l'environement est dans un état $e \in \mathbb{E}$.
L'acteur observe l'environement au travers d'un interpréteur, qui lui renvoie un vecteur $s \in \mathbb{S}$, le vecteur d'observation.
L'acteur à la possibilité de réalisé une action $a \in \mathbb{A}$ pour influancé l'environement.
Suite à cette action, l'environement change d'état, et renvoie à l'acteur un nouveau vecteur d'observation et une récompence $r \in \R$.
Cette récompence permet de quantifier la qualité de l'action et du nouvel état.
Ainsi à l'instant $t$, l'environnement est dans un état $e \in \mathbb{E}$.
L'acteur observe l'environnement au travers d'un interpréteur qui lui renvoie un vecteur $s \in \mathbb{S}$, le vecteur d'observation.
L'acteur a la possibilité de réaliser une action $a in \mathbb{A}$ pour influencer l'environnement.
Suite à cette action, l'environnement change d'état et renvoie à l'acteur un nouveau vecteur d'observation et une récompense $r \in \R$.
Cette récompense permet de quantifier la qualité de l'action et du nouvel état.
Pour la suite, on notera $x ^ i$ la i-ème grandeur, et $x_t$ la grandeur à l'instant $t$.
Le but de l'acteur est de maximisé la récompence total qu'il va recevoire au cours d'un épisode, c'est à dire une succession de pas de temps.
Pour cela, l'acteur doit crée une fonction $\pi : \mathbb{S} \rightarrow \mathbb{A}$ permetant de donner l'action optimal à réaliser pour chaque état.
Le but de l'acteur est de maximiser la récompense totale qu'il va recevoir au cours d'un épisode, c'est-à-dire une succession de pas de temps.
Pour cela, l'acteur doit créer une fonction $\pi : \mathbb{S} \rightarrow \mathbb{A}$ permettant de donner l'action optimale à réaliser pour chaque état.
La solution optimal est définie comme l'action permetant de maximiser le retour global : \begin{equation}
R = sum_{i = 1} ^\infty r _ i \gamma ^ i
\label{eq:rl:R}
\end{equation}
La methode de base pour construire cette fonction est le \qlearn{}.
C'est un possecus itératif où l'ont va construire un tableau (la Q-table), noté $\mathbb{Q} : \mathbb{S} \times \mathbb{A} \rightarrow \R$ associant à chaque couple observation/action une valeur.
On parcours l'environement et à chaque pas de temps, on met à jour la valeur de $\mathbb{Q}(s_t, a_t)$ grace à la formule suivante : \begin{equation}
La méthode de base pour construire cette fonction est le \qlearn{}.
C'est un processus itératif où l'on va construire un tableau (la Q-table), noté $\mathbb{Q} : \mathbb{S} \times \mathbb{A} \rightarrow \R$ associant une valeur à chaque couple observation/action.
On parcourt l'environnement et à chaque pas de temps on met à jour la valeur de $\mathbb{Q}(s_t, a_t)$ grâce à la formule suivante : \begin{equation}
\mathbb{Q}\left(s_t, a_t \right) := \left(1 - \alpha\right) \cdot \mathbb{Q}\left(s_t, a_t \right) + \alpha \cdot \left( r_t + \gamma \cdot max _ {a \in \mathbb{A}} \mathbb{Q} \left((s_{t+1}, a \right) \right)
\label{eq:qlearn_update}
\end{equation}
Les deux paramètre sont : \begin{itemize}
\item $\alpha$ le taux d'apprentissage, c'est à dire à quelle point les nouvelles informations écrasent les anciennes,
\item $\gamma$ l'horizon, qui permet de controler à quelle point l'algorithme se préocupe du future.
Les deux paramètres sont : \begin{itemize}
\item $\alpha$ le taux d'apprentissage, c'est-à-dire à quel point les nouvelles informations écrasent les anciennes,
\item $\gamma$ l'horizon, qui permet de contrôler à quel point l'algorithme se préoccupe du futur.
\end{itemize}
La méthode pour choisir quelle action prendre à chaque pas de temps est juste de prendre $argmax_{a \in \mathbb{A}} \mathbb{Q}\left(s_t, a \right) $.
En réalité, on fait des actions aléatoire avec une probabilité faible pour exploré l'environement.
Deux des limites de cette solution sont la taille en mémoire d'un tel tableau quand les ensembles $mathbb{S}$ et $\mathbb{A}$ sont grands, et le temps qu'il faut pour que la convergence des valeur du tableau ais lieu.
Pour palié à cela, on peut approximé la fonction par un réseau de neurrone, c'est le principe du \dqlearn{}.
La méthode pour déterminer l'action appropriée à chaque pas de temps est juste de prendre $argmax_{a \in \mathbb{A}} \mathbb{Q}\left(s_t, a \right) $.
En réalité, on fait des actions aléatoires avec une probabilité faible pour explorer l'environnement.
Deux des limites de cette solution sont la taille en mémoire d'un tel tableau quand les ensembles $mathbb{S}$ et $\mathbb{A}$ sont grands, et le temps qu'il faut pour que la convergence des valeurs du tableau ait lieu.
Pour pallier à cela, on peut approximer la fonction par un réseau de neurones, c'est le principe du \dqlearn{}.
\section{État de l'art\label{part_cc}}
Le \CC{} est un problème qui date du début des réseaux.
La première version de \tcp{} date de 1983, mais de nouveau \CCA{} sont régulièrement publiés et mis en production.
Comme ordre d'idée, le \CCA{} le plus utilisé de nos jour, \cubic{}, a été inclue dans Linux en 2006, dans MacOS en 2014 et dans Windows en 2017.
Chaque \CCA{} a des avantage et inconvénient, et ne fait pas le même compromis entre delai et débit.
La première version de \tcp{} date de 1983, mais de nouveaux \CCA{} sont régulièrement publiés et mis en production.
Comme ordre d'idées, le \CCA{} le plus utilisé de nos jours, \cubic{}, a été inclus dans Linux en 2006, dans MacOS en 2014 et dans Windows en 2017.
Chaque \CCA{} présente des avantages et des inconvénients, et ne fait pas le même compromis entre délai et débit.
\begin{figure}[htp]
\centering
\includegraphics[width = 0.8\textwidth]{png_img/comp_tcp_xiao.png}
\caption[Comparaison des \CCA{} en \tcp{}]{Comparaison de différents \CCA{} en \tcp{}. Figure issu de \cite{xiaoTCPDrincSmartCongestion2019}.}
\caption[Comparaison des \CCA{} en \tcp{}]{Comparaison de différents \CCA{} en \tcp{}. Figure issue de \cite{xiaoTCPDrincSmartCongestion2019}.}
\label{fig:comp_cca_tcp}
\end{figure}
\subsection{Comment gère-t-on la congestion en \tcp{} ?}
Le \tcp{} suppose que il y a un grand nombre de paquet à transmettre.
Ainsi on décide d'une fenetre de congestion, c'est à dire le nombre de paquet en attente d'aquitement.
Si un paquet n'est pas aquité avant la fin d'un \rto{} fixe, on le réenvoie.
Les \CCA{} on pour rôle de gérer la taille de la fenetre, et le \rto{} pour optimisé la connexion.
Le \tcp{} suppose qu'il y a un grand nombre de paquets à transmettre.
Ainsi on décide d'une fenêtre de congestion, c'est-à-dire le nombre de paquets en attente d'acquittement.
Si un paquet n'est pas acquitté avant la fin d'un \rto{} fixe, on le renvoie.
Les \CCA{} ont pour rôle de gérer la taille de la fenêtre, et le \rto{} celui d'optimiser la connexion.
Les \CCA{} de \tcp{} sont nombreux (une classification partiel est lsible dans \cite{haileEndtoendCongestionControl2021}), il ne seront donc pas tous décrit.
Le principe de base de la plupart des algoritmes est l'AIMD (additive-increase-multiplicative-decrease).
Par exemple \newreno{}, le prédececeure de \cubic{}, augmente la taille de la fenetre par pas de $1$ tout les \rtt{}, et multiplie la taille par $\frac{1}{2}$ en cas de détéction de congestion.
L'évolution proposé par \cubic{} est de ne pas venir croitre linéairement, mais de suivre une courbe cubique pour revenir en douceur à la taille de fenetre qui avait causé la congestion.
Les \CCA{} de \tcp{} sont nombreux (une classification partielle est lisible dans \cite{haileEndtoendCongestionControl2021}), ils ne seront donc pas tous décrit.
Le principe de base de la plupart des algorithmes est l'AIMD (additive-increase-multiplicative-decrease).
Par exemple \newreno{}, le prédecesseur de \cubic{}, augmente la taille de la fenêtre par pas de $1$ tous les \rtt{}, et multiplie la taille par $\frac{1}{2}$ en cas de détection de congestion.
L'évolution proposée par \cubic{} est de ne pas croître linéairement mais de suivre une courbe cubique pour revenir en douceur à la taille de fenêtre qui avait causé la congestion.
Dans les deux cas, à chaque retransmission d'un message, le \rto qui lui est accordé double.
D'autre \CCA{} utilise les variations du \rtt{} pour estimer l'état de congestion du réseau.
Le \rtt{} est le temps qui sépparre l'émittion d'un paquet de la reception de l'aquitement.
D'autres \CCA{} utilisent les variations du \rtt{} pour estimer l'état de congestion du réseau.
Le \rtt{} est le temps qui sépare l'émission d'un paquet de la réception de l'acquittement.
Le \rtt{} est composé de deux parties : \begin{itemize}
\item le temps de propagation, qui correspont au temps que met le signal à faire le trajet, il est incompressible (sauf changement de route),
\item le temps de propagation, qui correspond au temps que met le signal à faire le trajet ; il est incompressible (sauf changement de route),
\item le temps d'attente dans les queues, qui est le temps passé dans les queues des différents routeurs et qui dépend dirrectement de la congestion du réseau.
\end{itemize}
Ainsi l'augmentation du \rtt{} est souvent signe que le réseau se congestionne.
Mais interpréter ces varriation de \rtt{} et prendre la décision adécoite est trop complexe pour un algoritme classique, et certain on déjà proposé des solutions utilisant de l'IA \cite{xiaoTCPDrincSmartCongestion2019,liQTCPAdaptiveCongestion2019} .
Mais interpréter ces variations de \rtt{} et prendre la décision adéquate est trop complexe pour un algorithme classique, et certains ont déjà proposé des solutions utilisant de l'IA \cite{xiaoTCPDrincSmartCongestion2019,liQTCPAdaptiveCongestion2019} .
\subsection{Comment gère-t-on la congestion avec l’implémentation classique de \coap{} ?}