111

Mécanismes de Contrôle de Congestion

Realisé :

KNADEL Idriss

2012/2013

Proposé par :

Mr Idboufker

222

Plan

Algorithmes basique de CC

Algorithmes de CC

Conclusion

Introduction

CC = adaptation à la bande passante disponible à

chaque instant

Congestion = routeur avec file d'attente pleine

Rejet/perte de paquet (car débordement mémoire routeur).

Délais importants de transfert (car attente dans les files des

routeurs).

3

Contrôle de flux : par rapport au récepteur

◦ l'émetteur adapte le nombre de paquets envoyés à la taille du

buffer de réception

Contrôle de congestion : par rapport au réseau

◦ l'émetteur adapte le débit des données envoyées à la bande

passante instantanée du réseau

=> NB : ce n'est pas la taille des paquets, mais leur débit d'envoi

qui change

4

Les algorithmes basiques de CC supportés par TCP

sont [RFC 2581] :

◦ Slow start

◦ Congestion avoidance

◦ Fast retransmission

◦ Fast recovery

5

L’idée est d’émettre de plus en plus jusqu‘à

l'observation d'une congestion.

A partir de la essayer de réguler l‘émission pour

supprimer la congestion .

Au niveau TCP , l'observation de la perte d'un paquet

est assimilé à un début de congestion.

6

Taille de la Fenêtre de congestion « cwnd ».

Seuil de démarrage lent « ssthresh »

- Estimation de la bande passante disponible

RTT (Round Trip Time)

7

But : retrouver rapidement la bande passante

Disponible◦ Initialement « cwnd=1 ».

◦ ssthresh = valeur prédéterminée.

◦ cwnd *= 2 à chaque RTT (croissance exponentielle).

◦ Si atteinte ssthresh :

on entre en congestion avoidance

◦ Si perte :

ssthresh = cwnd / 2

cwnd = 1

on relance le slow start.

8

But : augmenter le débit en testant gentiment la bande

passante disponible.

Utilisé quand cwnd >= ssthresh.

◦ cwnd = cwnd +1 à chaque RTT (croissance linéaire).

◦ Si perte :

ssthresh = cwnd / 2

cwnd = 1

retour au mode slow start

9

10

But : détecter plus rapidement la perte d'un paquet (et le retransmettre).

DupACK : un accusé identique au précédent◦ – si paquet N arrive au récepteur avant N-1, son accusé est

identique à l'accusé de N-2.

Fast retransmission : si N dupacks, on n'attend plus le timeout, mais :◦ on retransmet le paquet

◦ on entre en slow start (Tahoe) ou fast recovery (les autres)

11

But: permet d’ éviter que le canal de communication ne

soit vide évitant ainsi le besoin de démarrer le slow

start pour le remplir de nouveau.

Cwnd= ssthresh/2 ( si réception de N dupACK).

Cwnd = cwnd +1 à chaque RTT (croissance linéaire).

12

Tahoe : slow start + congestion avoidance + fast

retransmission.

Reno : Tahoe + fast recovery.

Newreno : Reno + adaptation aux pertes successives.

Vegas : basé sur l'historique du RTT (état des routeurs).

Westwood+ : basé sur l'historique du RTT, meilleure

utilisation si pertes aléatoires

Beaucoup d'autres...

13

Perte <=> timeout ou 3 dupacks

Utilise :

◦ Slow start

◦ Congestion avoidance

◦ Fast retransmission

14

TCP Reno est la variante la plus populaire.

Reno = Tahoe + fast recovery

TCP Reno peut différencier entre les deux cas suivants:

◦ perte de paquet aperçue par le RTO (le réseau subit une

congestion sévère).

◦ perte de paquet aperçue par des acquittements dupliqués (la

congestion dans le réseau n’ est pas sévère)

15

16

Windows Vista : Compound TCP

Windows XP :TCP Reno (or New Reno)

Linux kernel 2.6.19 : CUBIC.

Linux up to kernel version 2.6.18: BIC

Il n'est pas aisé de parler de meilleure version TCP : il y

a des versions adaptées aux :

◦ Réseaux très hauts débits,

◦ Réseaux petits débits,

◦ Réseaux qui font beaucoup d'erreurs.

18

Contrôle de congestion dans le protocole TCP ( Eugen Dedu ).

Etudes de la consommation d’énergie de TCP

Tahoe, Reno, New-Reno, SACK, Vegas et WestwoodNR dans

les réseaux ad hoc ( Alaa Seddik Ghaleb*, Yacine Ghamri-

Doudane** et Sidi-Mohammed Senouci*).

Etude détaillée du protocole TCP Le contrôle de congestion

(M. Heusse, P. Sicard).

19