# PRS - Amphi 2

[Slides](https://moodle.insa-lyon.fr/pluginfile.php/180155/mod_resource/content/3/Cours_TCP.pdf)

###### tags : `PRS` `Amphi`

## TCP

**Slow Start :** On ne connait pas l'état du réseau au début de la connection $\longrightarrow$ On commence avec $cwnd = 1$
Pour chaque ACK reçu on fait $cwnd=cwnd+1$
En pratique, cwnd double pendant un intervalle RTT (Round Time Trip) du fait des faibles temps de transmission (on reçoit les ACK en même temps).
Le nom est un peu trompeur car la progression est exponentielle

*Rappel : cwnd = Congestion Window*


**Slow Start Treshold (sstresh) :** Seuil où l'on décide de passer de Slow Start à autre chose (Congestion Avoidance principalement).
Si je suis dans un réseau de faible capacité, le threshold est défini sur une valeur faible, ce qui implique un arrêt précoce du mécanisme Slow Start.
La valeur initiale est arbitraire (souvent très élevée). Après un segment perdu on pose $sstresh=\frac{FlightSize}{2}$. On repart de $cwnd=1$ jusqu'à ce que $cwnd = sstresh$


**Congestion Avoidance :** On entre dans ce mode si $cwnd > sstresh$. Dans ce cas au delà du seuil sstresh, $cwnd = cwnd + \frac{1}{cwnd}$. On l'utilise car Slow Start est un peu trop agressif.
Quand une congestion est détectée, on essaye d'éviter d'atteindre l'état de congestion de nouveau (on modifie $sstresh$ et on repart de $cwnd=1$ avec Slow Start jusqu'au $sstresh$)

**Fast Retransmit :** Un timeout peut être une indication très fiable de la congestion mais il peut être très long.
Un seul Duplicate ACK n'est pas forcément synonyme de perte. On ne considère pas un segment perdu après un Duplicate ACK mais après 3 Duplicate ACKs (4 ACKs consécutifs du même segment)
Ne marche pas si la fenêtre de congestion est trop petite (pas possible d'avoir plus de 3 ACKs de suite)

D'après de vieux tests :
- On évite la moitié des timeout
- On a une augmentation de 20% du débit


**Fast Recovery :** Si on reçoit un ACK dupliqué on en déduit qu'il y a un segment qui manque mais aussi que des segments postérieurs sont bien arrivés $\longrightarrow$ le réseau marche (cf ack dupliqués amphi 1).
La congestion est passée, il n'est donc pas nécessaire de repasser par Slow Start dans ce cas.
Fast Recovery est actif après la réception de 3 Duplicate ACKs. On pose $sstresh=\frac{FlightSize}{2}$ et on retransmet le packet perdu. Au lieu de repartir de $cwnd=1$, on pose $cwnd = sstresh+n_{dup}$ ($n_{dup}$ est le nombre de Duplicate ACKs reçus). Ce changement s'effectue un RTT après la réception de l'ACK manquant.
On évite Slow Start et on repart directement sur Congestion Avoidance.


**Selective Acknoledgements :**
Le récepteur ne peut que ACK des segments adjacents (dernier segment reçu en continu). L'envoyeur n'a pas de feedback sur quels segments ont été reçus correctement ou non. Idéalement, il ne devrait rennvoyer que les segments manquants et pas tous les segments qui suivent.

**Delayed ACK :** On attend pour envoyer un ACK (retard de 500ms au max). Assez utile en HTTP, celà permet d'envoyer les ACK une fois tout les segments constituant la page envoyés et de gagner ainsi du temps de chargement de page. Utile pour implémenter du *piggy-backing* qui consiste à encapsuler à la fois de la donnée et l'ACK de la transmission précédente dans le même segment.

**Algorithme de Nagle :**
On combine des petites quantités de données dans un seul segment (plutôt que d'en transmettre plusieurs). Si on ne reçoit pas l'ACK d'un segment, on continue de stocker des données dans le buffer jusqu'à l'nevoi d'un segment complet.
Ne fonctionne pas bien avec *Delayed ACK*.

**TCP Cubic :** La taille de la fenêtre de congestion n'est plus gérée par la réception des ACKs. $cwnd$ est calculée en fonction du temps écoulé depuis la dernière congestion.
Trois phases (*cf schéma*) :
- Départ agressif jusqu'à sstresh (comme Slow Start)
- On ralentit la progression ensuite
- On repasse sur une augmentation forte pour aller chercher le maximum


## QUIC - Quick UDP Internet Connections

Implémentation d'un couche transport dans l'espace utilisateur sur des sockets UDP.
Créé par Google en 2013. Porte aujourd'hui entre 5% et 10% du trafic Internet mondial. Utile pour les recherches web et le visionnage de vidéos.