Rapport Final Projet Simulation
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Rapport Final Projet Simulation as PDF for free.
More details
- Words: 2,096
- Pages: 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 ^
`
LI ! WHPSV ^
SULQWI I?WI?QWHPSVGHELW
GHELW
WHPSV
`
GHELW GHELW
` ` (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 ^
`
LI ! WHPSV ^
SULQWI I?WI?QWHPSVQEBSNWBGURSSHQEBSNWBHQYR\H
WHPSV
`
`
QEBSNWBHQYR\H
` ^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 ^
`
LI ! WHPSV ^
SULQWI I?WI?QWHPSVGHELW
GHELW
WHPSV
`
GHELW GHELW
` ` (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 ^
`
LI ! WHPSV ^
SULQWI I?WI?QWHPSVGHELW
GHELW
WHPSV
`
GHELW GHELW
` ` (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 cidessus:
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
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 ^
`
LI ! WHPSV ^
SULQWI I?WI?QWHPSVGHELW
GHELW
WHPSV
`
GHELW GHELW
` ` (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 ^
`
LI ! WHPSV ^
SULQWI I?WI?QWHPSVQEBSNWBGURSSHQEBSNWBHQYR\H
WHPSV
`
`
QEBSNWBHQYR\H
` ^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 ^
`
LI ! WHPSV ^
SULQWI I?WI?QWHPSVGHELW
GHELW
WHPSV
`
GHELW GHELW
` ` (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 ^
`
LI ! WHPSV ^
SULQWI I?WI?QWHPSVGHELW
GHELW
WHPSV
`
GHELW GHELW
` ` (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 cidessus:
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
Related Documents
Rapport Final Projet Simulation
June 2020 13
Rapport Projet
November 2019 29
Rapport De Projet
November 2019 19
Rapport Projet Fin
November 2019 14
Rapport Projet Corpsv2
November 2019 16