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 « slow-

start » 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]”