28
2 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 : 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. 1000000 / ) 8 * _ ( paquet taille débit =

Rapport Final Projet Simulation

  • Upload
    pamido

  • View
    1.237

  • Download
    8

Embed Size (px)

Citation preview

Page 1: Rapport Final Projet Simulation

2

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 :

������������ ���������� ������������������������������ ������ � ����� !� ����"������ � � ���� ����� �"���#$%��� � ��� � ����� &�� ����"������ � � ���' ���(�) (�)'�* ����*���� +����������� � � ���� ���#��� � � ����""��� � ��������,����

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.

1000000/)8*_( paquettailledébit =

Page 2: Rapport Final Projet Simulation

3

La taille de la file entre le nœud n1 et n2 est extraite grâce au script awk suivant :

���������������������"����� �������������� ������ ������-./0 ��1230� ����� �����42�55���5�""��� ��������' ���(�) (�)'�* ����*42�55���5����� �����-./0 ��1230� ���� ����� -./0 ��1230� ���� ����� ��� �������+67+���� �������������� ����� �� ������-./0 ��1230� ����� �����42�55���5�""��� ��������' ���(�) (�)'�* ����*42�55���5����� �����-./0 ��1230� ���� ����� 42�55���5�77��� ���' ���(�) (�)'�*� *42�55���5����� �����+6�+���� �������������� ����� � -./0 ��1230� ��� �� ������,����

Page 3: Rapport Final Projet Simulation

4

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 :

������������ ���������� ���

��������������������������� �����

� � ����� !� ����"�����

� � � ���� ����� �"���#$%��

� � ��

� � ����� &�� ����"�����

� � � ���' ���(�) (�)'�* ����*���� +����������

� � � ���� ���#��

� � � ����""��

� � ��

��

��

��,����

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.

Page 4: Rapport Final Projet Simulation

5

Le taux de perte des paquets est extrait grâce au script awk suivant :

�������������

���������7�����������������������

� � ����� !� ����"�����

� � � '�8�9 8�':/;�""��

� � ��

� � ����� &�� ����"�����

� � � ���' ���(�) (�)'�* ����*'�8�9 8��/���+'�8�9 8�':/;����

� � � ����""��

� � ��

� ��

��

�������������

� � '�8�9 8��/���""��

� ��

��

��,����

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.

ondeparenvoyésPktTotaldroppésPktPerteTaux sec_)__/_(_ =

Page 5: Rapport Final Projet Simulation

6

Question 2

Le débit de sortie du trafic TCP est extrait grâce au script awk suivant :

������������ ���������� ���

��������������������������� ������<� =������

� � ����� !� ����"�����

� � � ���� ����� �"���#$%��

� � ��

� � ����� &�� ����"�����

� � � ���' ���(�) (�)'�* ����*���� +����������

� � � ���� ���#��

� � � ����""��

� � ��

��

��

��,����

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

Page 6: Rapport Final Projet Simulation

7

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 :

������������ ���������� ���

��������������������������� ������<�=�������

� � ����� !� ����"�����

� � � ���� ����� �"���#$%��

� � ��

� � ����� &�� ����"�����

� � � ���' ���(�) (�)'�* ����*���� +����������

� � � ���� ���#��

� � � ����""��

� � ��

��

��

��,����

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

Page 7: Rapport Final Projet Simulation

8

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

Page 8: Rapport Final Projet Simulation

9

Le code TCL de la simulation

Page 9: Rapport Final Projet Simulation

10

Page 10: Rapport Final Projet Simulation

11

Page 11: Rapport Final Projet Simulation

12

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:

Page 12: Rapport Final Projet Simulation

13

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

Page 13: Rapport Final Projet Simulation

14

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)

Page 14: Rapport Final Projet Simulation

15

La topologie de la simulation

Le code TCL de la simulation

Page 15: Rapport Final Projet Simulation

16

Page 16: Rapport Final Projet Simulation

17

Page 17: Rapport Final Projet Simulation

18

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:

Page 18: Rapport Final Projet Simulation

19

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

Page 19: Rapport Final Projet Simulation

20

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.

Page 20: Rapport Final Projet Simulation

21

New Reno Théorique

New Reno par Simulation

Page 21: Rapport Final Projet Simulation

22

La topologie de la simulation New Reno

La topologie de la simulation Tahoe

Page 22: Rapport Final Projet Simulation

23

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.

Page 23: Rapport Final Projet Simulation

24

Le code TCL de la simulation : Tahoe

Page 24: Rapport Final Projet Simulation

25

Page 25: Rapport Final Projet Simulation

26

Page 26: Rapport Final Projet Simulation

27

Le code TCL de la simulation : New Reno

Page 27: Rapport Final Projet Simulation

28

Page 28: Rapport Final Projet Simulation

29