Project Inf7345

PROJET DE SIMULATION

(Travail individuel à rendre le 1 décembre 2008)

Partie I

Développez une topologie de réseau qui devrait contenir au moins un nœud intermédiaire. Employez les protocoles TCP et UDP avec ftp et le trafic CBR, respectivement. Assurez-vous qu’il y a un lien congestionné (lien de goulot). 1. Prenez les mesures de toute la sortie de ce lien, en fonction du temps (graphique 1). 2. Prenez les mesures du débit de la sortie de ce lien en fonction du temps, seulement pour des paquets de TCP (graphique 2). 3. Prenez les mesures de la sortie de ce lien en fonction du temps, seulement pour des paquets d'UDP (graphique 3). 4. Employez le NAM pour visualiser la topologie de réseau. 5. Utilisez les programmes xgraph ou gnuplot pour tracer les 3 graphiques. 6. Préparez un rapport succinct contenant : le code TCL, et une discussion courte au sujet paramètres utilisés et des résultats de la topologie choisie.

Partie II

Pour cette partie, employez seulement une connexion TCP avec le trafic ftp. 1. Au cours de la simulation, enregistrez la valeur de la fenêtre de congestion de TCP, en fonction du temps (graphique 1) et tracer le graphique 1. 2. Préparez un rapport succinct contenant : le code TCL, un screenshot de la topologie que vous avez employée, et le graphique, aussi bien qu’une discussion courte au sujet paramètres utilisés et des résultats de la topologie choisie. Note : Un agent TCP a un certain nombre de variable d'état que vous pouvez employer : window_ : la fenêtre annoncée du récepteur – la borne maximum sur la taille de la fenêtre cwnd_: fenêtre de congestion (paquets) ssthresh_ : le seuil du slow-start (paquets) L'agent TCP « Tahoe » effectue la commande de congestion, en utilisant « slowstart » et «congestion avoidance ». La fenêtre de congestion (cwnd_) est augmentée par un paquet à chaque nouvel ACK reçu pendant slow-start (quand cwnd_ < ssthresh_) et est augmentée par (1∕cwnd_) à chaque nouvel ACK reçu pendant congestion avoidance (quand cwnd_ ≥ ssthresh_).

TCP Tahoe suppose qu'un paquet est perdu (en raison de la congestion) quand il observe 3 ACKs dupliqués, ou quand le temporisateur de retransmission expire. Dans l'un ou l'autre cas, TCP Tahoe réagit en plaçant le ssthresh_ à la moitié de la taille courante de fenêtre (le minimum de cwnd_ et de window_). Il initialise alors le cwnd_ de nouveau à 1. Ceci fera typiquement entrer TCP à la phase slow-start. Dans cet exercice, créez un agent TCP par : « set tcp_agent [new Agent/TCP] » en appelant « Agent/TCP », il crée un émetteur TCP « Tahoe ». Vous pouvez employer les valeurs suivantes : Taille du buffer : 5 paquets Seuil de congestion : 20 (Agent/TCP set ssthresh_ 20) Fenêtre annoncée : 20 (Agent/TCP set window_ 20) Le trafic ftp : Commencez à 0.1 sec - arrêtez à 5.0 sec Temps de simulation : 5.1 sec Intervalle = 0.01 - mesures prises toute les 0.01 sec

Partie III

Créez deux scripts séparés : un pour l'usage d'un agent TCP Tahoe et l’autre utilisant TCP New-Reno. Pour les deux scripts : 1. Enregistrez la valeur de la fenêtre de congestion de TCP, en fonction du temps (graphique 1 et 2). 2. Prenez les mesures du débit du lien de goulot, en fonction du temps. 3. Tracer les graphiques : Graphique 1 : Fenêtre de congestion en fonction du temps, utilisant l'agent TCP Tahoe Graphique 2 : Fenêtre de congestion en fonction du temps, utilisant l'agent TCP New-Reno Graphique 3 : Débit en fonction du temps, pour TCP Tahoe et New-

Reno

Pour tracer le graphique 3, employez une fenêtre de terminal pour exécuter la commande suivante (après que vous exécuter le script de NS) : « $xgraph throughput_tahoe.data throughput_newreno.data & » 4. Préparez un rapport succinct contenant: le code TCL, un screenshot de la topologie que vous avez employée, et les graphiques, aussi bien qu’une discussion courte au sujet paramètres utilisés et des résultats de la topologie choisie (discuter la différence entre TCP Tahoe et New-Reno). Note : L'émetteur TCP devrait employer l'algorithme Fast Retransmit pour détecter et recouvrir la perte, en se basant sur les ACKs dupliqués entrant. L’algorithme Fast Retransmit utilise l'arrivée de 3 ACKs dupliqués comme indication qu'un segment a

été perdu. Après réception de 3 ACKs dupliqués, TCP effectue une retransmission de ce qui semble être le segment manquant, sans attendre l’expiration du temporisateur de retransmission. Quand le mécanisme Fast Retransmit signale une congestion, plutôt que remettre la fenêtre de congestion à 1 et retourner à slow-start, est utilisé afin d’éliminer la phase slow-start. Fast Retransmit va simplement diviser la fenêtre de congestion sur 2 et effectue une augmentation additive (additive increase). Autrement dit, slow-start est utilisé juste au début de la connexion et à chaque fois que le temporisateur expire. Sinon, AIMD (Additive Increase Multiplicative Decrease) est toujours utilisé. En NS-2, un agent TCP New Reno est appelé par: “set tcp_agent [new Agent/TCP/Newreno]”