You are on page 1of 28

Partie I

La topologie est constituée de trois nœuds n0, n1 et n2. Le lien congestionné est
entre n1 et n2. Pour simuler la congestion de ce lien, nous avons diminué sa capacité a
0.9MB et nous avons fixé la capacité du lien entre n0 et n1 a 2MB. Nous avons aussi
augmenté l'inter arrivée des paquets du trafic CBR a 0.005 seconde.

Question 1
Nous allons prendre toutes les mesures de sortie que nous avons jugé utiles à
exposer :
Débit de sortie en Mbits par secondes entre le nœud n1 et n2
Taille de la file entre le nœud n1 et n2
Débit de perte en Mbits par secondes
Taux de perte des paquets en secondes

Le débit de sortie entre le nœud n1 et n2 est extrait grâce au script awk suivant :

%(*,1^)6 WHPSV GHELW `


^LI  U     ^
  LI  WHPSV ^
   GHELW GHELW   
  `
  LI ! WHPSV ^
   SULQWI I?WI?QWHPSVGHELW 
   GHELW 
   WHPSV
  `
`
`
(1'^`

D’après le fichier de trace qu'on a généré, nous allons traiter les paquets qui ont
étaient reçus par le nœud n2 dans chaque seconde, ensuite on multiplie la taille des
paquets par 8 pour avoir les résultats en bits, ensuite on imprime le temps et le débit
obtenu.
débit = (taille _ paquet * 8) / 1000000

2
La taille de la file entre le nœud n1 et n2 est extraite grâce au script awk suivant :
%(*,1^)6 `
^LI   ^
 LI     ^

 LI $MRXWHU3DTXHW  ^
 7DLOOH)LOH
 SULQWI I?WG?QWHPSV7DLOOH)LOH 
 $MRXWHU3DTXHW 
 `
 $MRXWHU3DTXHW 
 WHPSV 
 `
`
`

A^
 LI     ^
 
 LI $MRXWHU3DTXHW  ^
 7DLOOH)LOH
 SULQWI I?WG?QWHPSV7DLOOH)LOH 
 $MRXWHU3DTXHW 
 `
 7DLOOH)LOH
 SULQWI I?WG?Q7DLOOH)LOH 
 `
`

AG^
 LI     ^
  $MRXWHU3DTXHW  
 `
`
(1'^`

3
Grâce au fichier de trace qu'on a généré, nous avons pu surveiller les paquets qui
sont entrées et sortis de la file pendant le temps de la simulation. En sachant que ns2 ne
droppe pas les paquets directement quand la file est pleine, nous avons ajouté la variable
booléenne AjouterPaquet pour savoir quand considérer que l'opération et un ajout ou un
retrait de la file. Les résultats obtenus sont représentés par le graphe suivant :

Le débit de perte entre le nœud n1 et n2 est extrait grâce au script awk suivant :
%(*,1^)6 WHPSV GHELW `
^LI  G     ^
  LI  WHPSV ^
   GHELW GHELW   
  `
  LI ! WHPSV ^
   SULQWI I?WI?QWHPSVGHELW 
   GHELW 
   WHPSV
  `
`
`
(1'^`
Comme pour le débit, le code reste le même, on change seulement le type de
paquets a traité, tout a l'heure nous surveillons les paquets reçus, maintenant, nous
surveillons les paquets droppés, et comme ca nous aurons le débit de perte a chaque
seconde.

4
Le taux de perte des paquets est extrait grâce au script awk suivant :
%(*,1^)6 `
^LI       ^
  LI  WHPSV ^
   QEBSNWBHQYR\H
  `
  LI ! WHPSV ^
   SULQWI I?WI?QWHPSVQEBSNWBGURSSHQEBSNWBHQYR\H 
   WHPSV
  `
 `
`

^LI  G ^
  QEBSNWBGURSSH
 `
`
(1'^`
Chaque fois qu'un paquet est droppé, le taux de perte augmente, nous avons
essayé de surveiller ce taux tout au long de la simulation. Pour cela, nous avons calculé le
nombre de paquets envoyés dans chaque seconde et on a calculé le nombre de paquet
droppé dans chaque seconde aussi. Ensuite nous avons fait le rapport.
Taux _ Perte = ( Pkt _ droppés / Total _ Pkt _ envoyés) par _ sec onde

5
Question 2
Le débit de sortie du trafic TCP est extrait grâce au script awk suivant :
%(*,1^)6 WHPSV GHELW `
^LI  U      WFS ^
  LI  WHPSV ^
   GHELW GHELW   
  `
  LI ! WHPSV ^
   SULQWI I?WI?QWHPSVGHELW 
   GHELW 
   WHPSV
  `
`
`
(1'^`

Le script de calcul du débit est le même, nous avons juste ajouté une condition
supplémentaire pour pouvoir filtrer le trafic TCP. Dans le fichier de trace, nous avons
constaté que le 5ième champ caractérise le type de trafic du paquet, Exemple :
- 14.737867 1 2 cbr 500 ------- 2 0.1 2.1 2699 3224 : Protocole UDP
r 14.738978 1 2 tcp 1040 ------- 1 0.0 2.0 233 3220 : Protocole TCP

6
Interprétation des résultats
D'après le graph, nous remarquons que TCP ne présente pas un haut débit, cela est
compréhensible vu qu'il y a du trafic UDP en parallèle qui consomme toute la bande
passante du lien et vu que TCP est conscient de la congestion alors il diminue son débit.

Question 3
Le débit de sortie du trafic UDP est extrait grâce au script awk suivant :
%(*,1^)6 WHPSV GHELW `
^LI  U      FEU ^
  LI  WHPSV ^
   GHELW GHELW   
  `
  LI ! WHPSV ^
   SULQWI I?WI?QWHPSVGHELW 
   GHELW 
   WHPSV
  `
`
`
(1'^`

De même pour UDP, on ajoute juste la condition pour filtrer le trafic.

7
Interprétation des résultats
D'après le graph, nous remarquons que UDP commence progressivement à
augmenter son débit, jusqu'à utilisé presque toute la bande passante du lien et de ce fait
créer une congestion au niveau du lien. UDP ne détecte pas la congestion, et ne reçoit pas
d'Ack de la part de la destination donc il continu a envoyé ces paquets.

Question 4
Employez le NAM pour visualiser la topologie de réseau

8
Le code TCL de la simulation

9
10
11
Partie II
Pour cette partie, nous avons employé seulement une connexion TCP avec le
trafic FTP. Le but de cette partie est d'étudier TCP Tahoe à travers la simulation. Nous
avons choisit une topologie simple, trois nœuds, le nœud intermédiaire constitue un
étranglement, cet étranglement est simulé par un lien a faible bande passante entre le
nœud intermédiaire et la destination et avec un buffer de capacité 5 paquets. Avec les
résultats obtenus de la simulation, nous allons expliquer le comportement de TCP face a
la congestion et détailler les mécanismes utilisés pour diminuer la congestion. Pour cela,
nous avons surveillé la taille de la fenêtre de congestion cwnd au cours de la simulation,
et nous avons obtenus les résultats suivants qui sont représentées par le graphique ci-
dessus:

12
TCP Tahoe est composé de trois phases : Slow Start, Congestion Avoidance, Fast
Retransmission
TCP Tahoe, slow start
Le but est de retrouver rapidement la bande passante disponible, ce mécanisme est
observé pour la première fois dans l'intervalle de temps entre [0,0.4] secondes.
La taille de la cwnd = 1, et a chaque accusé reçu cwnd augmente (cwnd *= 2 à chaque
RTT) : croissance exponentielle.
Ssthresh = 20, quand TCP a atteint ssthresh, encore dans le même intervalle de temps
[0,0.4], TCP entre dans la phase de congestion avoidance.
Il y a perte ; t = 0.41 seconde
cwnd =1 ; t = 0.42 seconde
et TCP relance le slow start ; t = 0.5 seconde

13
TCP Tahoe, Congestion avoidance
Le but est d'augmenter le débit en testant progressivement la bande passante
disponible.
Cwnd augmente à chaque RTT : croissance linéaire
Il y a eu perte ; t = 0.83 seconde
cwnd = 1 ; t = 0.85 seconde
retour au mode slow start ; t = 0.90

TCP Tahoe, Fast Retransmission


Le but est de détecter plus rapidement la perte d'un paquet et le retransmettre. Un
paquet est considéré par l'émetteur comme perdu si :
• pas d'accusé au timeout (pertes successives), déjà traité
• ou bien réception de N dupacks, N = 3 en générale. (perte isolée)
Fast retransmission : si N dupacks, TCP n'attend plus le timeout, mais :
• retransmet le paquet
• et entre en slow start (Tahoe)

14
La topologie de la simulation

Le code TCL de la simulation

15
16
17
Partie III
Pour cette partie, nous avons généré deux scripts de simulation différents, l'un
avec TCP Tahoe comme la partie 2 et l'autre implémente TCP New Reno avec un trafic
FTP. Le but de cette partie est de comparer TCP Tahoe et TCP New Reno à travers la
simulation. Nous avons choisit une topologie simple, trois nœuds, le nœud intermédiaire
constitue un étranglement, cet étranglement est simulé par un lien à faible bande passante
entre le nœud intermédiaire et la destination et avec un buffer de capacité 5 paquets. Avec
les résultats obtenus de la simulation, nous allons expliquer le comportement des deux
TCP face a la congestion et détailler les mécanismes utilisés pour diminuer la congestion.
Pour cela, nous avons surveillé la taille de la fenêtre de congestion cwnd au cours de la
simulation, et nous avons obtenus les résultats suivants qui sont représentés par le
graphique ci-dessous:

18
TCP Tahoe est composé de trois phases : Slow Start, Congestion Avoidance, Fast
Retransmission et TCP New Reno est composé des mêmes phases que TCP Tahoe + Fast
Recovery + Adaptation aux pertes successives

19
Pour ce qui est de TCP Tahoe, les résultats obtenus dans la partie II reste les
mêmes, nous allons plus nous concentrer sur TCP New Reno et essayer de déceler les
points communs et les divergences.
Slow Start
Les deux protocoles sont identiques dans la première phase de slow start.
Congestion avoidance
Dans l'intervalle de temps [0,0.75], on remarque une légère différence entre Tahoe
et New Reno :
Tahoe cwnd = 1
New Reno cwnd = cwnd / 2 ensuite a t=0.75 sec cwnd = 1
Pendant que New Reno était en train de récupérer de la congestion, Tahoe a déjà
commencé à envoyer ses données.
Les deux protocoles présentent une croissance linéaire, cwnd augmente à chaque RTT.
Tahoe
Il y a eu perte ; t = 0.83 seconde //cwnd = 1 ; t = 0.85 seconde
retour au mode slow start ; t = 0.90
New Reno
Il y a eu perte a ; t = 1 sec
ssthresh (Seuil de démarrage lent) = cwnd / 2 ; t = 1 sec
cwnd = ssthresh ; t = 1.02 sec
retour au mode slow start ; t = 1.09
Grâce au mécanisme de fast recovey New Reno ne diminue pas sa fenêtre de congestion à
1 comme Tahoe, ce qui permet une rapide et meilleur reprise.
Fast Retransmission
Pour ce qui est du Fast Retransmission, les deux protocoles sont identiques.
Additive Increase Multiplicative Decrease
Slow start est utilisé juste au début de la connexion et à chaque fois que le temporisateur
expire. Sinon, Additive Increase Multiplicative Decrease) est toujours utilisé. Ce
mécanisme est implémenté seulement dans New Reno, il représente une augmentation
linéaire de la fenêtre de congestion, combinée avec une réduction exponentielle lors d'une
congestion.

20
New Reno Théorique

New Reno par Simulation

21
La topologie de la simulation New Reno

La topologie de la simulation Tahoe

22
Conclusion
Avec les résultats obtenus dans notre simulation, nous pouvons énumérer les
conclusions suivantes concernant TCP Tahoe et TCP New Reno :
TCP Tahoe
• Il est robuste face à la perte des paquets. Il peut détecter et retransmettre les
paquets perdus plus rapidement que les timeouts dans Tahoe.
• Il a un taux faible de retransmission
• les algorithmes Congestion Avoidance et Slow Start mesurent la congestion
naissante et la bande passante disponible d’une manière très précise, et donc
utilisent les ressources réseau efficacement et ne contribuent pas à la congestion.
TCP New Reno
• Il empêche plusieurs timeouts de New Reno vu qu’il n’a pas besoin d’attendre 3
Acks dupliqués pour retransmettre le paquet perdu.
• Sa Congestion Avoidance est plus performante à détecter la congestion naissante
et utilise les ressources du réseau plus efficacement que Tahoe.
• Grâce à la Congestion Avoidance et le Slow Start, il existe peut de
retransmissions.

23
Le code TCL de la simulation : Tahoe

24
25
26
Le code TCL de la simulation : New Reno

27
28
29

You might also like