Controle de congestion

Quand des paquets sont envoyés d’une machine à une autre sur Internet, ils peuvent traverser un certain

nombre de liens et de routeurs. Les liens ont des débits différents et les routeurs des vitesses de traitement

différents.

1 Routeur et congestion

Un routeur peut être représenté par un processeur, plusieurs buffers d’entrées, et plusieurs buffers de sortie.

Un paquet IP arrivant à un routeur par un lien est mis dans un des buffers en attendant d’être traité. Quand le

processeur du routeur considère le message il utilise les informations de destination contenues dans l’entête

IP pour décider du buffer de sortie où mettre le paquet.

1) Dans quelles circonstances les buffers d’entrée et de sortie peuvent-ils se remplir ? En entrée, si le débit

du lien entrant est supérieur à la vitesse de traitement des paquets, en sortie, si le débit du lien est trop faible

2) Quand les buffers sont pleins, le routeur jette les paquets sans avertir l’émetteur. On dit dans ce cas qu’il

y a congestion. Cette stratégie vous semble-t-elle raisonnable ou serait-il préferable d’avertir l’émetteur

? Si le routeur a ses buffers plein, c’est qu’il n’arrive pas à traiter tous les paquets. Prévenir l’émetteur

demanderait plus de traitement, ce qui agraverait la situation. D’un autre coté, ne pas le prévenir a pour

conséquence qu’il continuera à envoyer ses paquets au même rythme qu’avant, et que donc le problème

pourrait durer.

2 TCP

Du point de vue d’un émetteur de paquet, il est important de maximiser l’utilisation du réseau qui le relie

au destinataire, c’est à dire envoyer des paquets au débit maximal sans provoquer de congestion.

3) Est-ce qu’une connaissance parfaite des caractéristiques des chemins suivis par les paquets (débit maxi-

mum des liens, vitesse de traitement des routeurs) serait sufﬁsante ?

Seulement si nous étions les seuls à utiliser le lien. Il y a surement du trafﬁc transverse, donc le débit

max du lien n’est pas seulement pour nous

TCP est un protocole qui essaie de maximiser l’utilisation du réseau en évitant les congestions. Le

principe est le suivant :

• Quand une connexion TCP est établie, l’émetteur crée une fenêtre de congestion égale à 1 paquet, et

se ﬁxe une limite appelée threshold égale à 64Ko.

• Pour chaque paquet recu par le destinataire, un paquet d’aquitement (ACK) est envoyé.

• La fenêtre de congestion représente le nombre de paquets pouvant être en transit dans le réseau

• Quand l’émetteur recoit un ACK, il en conclue qu’il n’y a pas de problème sur le réseau.

• Lors de la reception d’un ACK, Si la fenêtre de congestion est inférieure à threshold elle voit sa taille

augmenter de paquet. C’est la phase de Slow Start

• Si la fenêtre a une taille n et est supérieure à threshold, alors lors de la reception d’un ACK, elle

n’est augmentée que de 1

/ n. C’est la phase de congestion avoidance.

• Quand un paquet est perdu, la fenêtre de congestion est remise à 1, et le threshold est divisé par 2

4) Comment TCP peut-il savoir qu’un paquet est perdu ? Il ne recoit pas d’ACK ou il recoit un ACK pour

un paquet hors séquence (ACK1, puis ACK3 par exemple).

5) Montrez que la fenêtre de congestion augmente de manière exponentielle dans la phase de slow start

La fenetre est initialement à 1, elle passe ensuite à 2. Quand les 2 paquets seront acquités, elle prendra

la valeur 4, puis 8,....

6) Montrez que la fenêtre de congestion augmente linéairement dans la phase de congestion avoidance

Quand toute la fenêtre a été acquitée, elle n’augmente que de n ∗ 1

7) On considère des paquets de taille 1K, combien de paquets vaut le treshold lors de l’ouverture d’une

connexion ? 64 paquets

8) Completez le diagramme suivant qui représente la taille de la fenetre de congestion en fonction du temps

(axe des x). Indiquez la taille du threshold au debut de la mesure, puis celle après la perte d’un paquet au

temps 13. Completez le diagramme en supposant qu’il n’y a plus de perte de paquets jusqu’au temps 24.

0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24Fenetre de CongestionTemps