RES240 / RES223

TP ns2 –
Analyse des protocoles de
transport par simulation
N. Boukhatem, D.Rossi Ressources: http://www.enst.fr/~drossi

La note finale de RES240/RES223 sera une moyenne ponderée de la note d'un examen (e.g., QCM, vrai ou
faux, question ouvertes et exercices), du compte rendu des TPs et eventuellement des TDs. Il est rappel que
votre présence aux TPs est obligatoire: afin d'éviter de mauvaises surprises, justifiez vos absences à l'avance.
Après chaque TP il faudra remettre un rapport: à noter que ce rapport sera noté. Le rapport devra être remis
dans un délai de maximum de 15 jours après la séance: au-delà, il ne sera pas pris en compte.
Le repport doit impérativement répondre à toutes les questions du TP et être parfaitement clair. Par contre, il
ne doit pas repondre au questions qui ne sont pas posés: donc, lisez bien ce qu'on vous demande. En règle
generale, il ne faut pas que les rapports de TP contiennent une explication de la théorie, car la verification de
vos connaissances de base sera plutot le but de l'examen. Par contre, il est important que vous expliquiez les
résultats obtenus, car votre travail sera évalué essentiellement sur ces commentaires. Au meme temps, les
commentaires seront evalués sur la base de leurs qualité plutot que de leurs quantité: donc, la dote de synthèse
sera appreciée. Il est donc necessaire que vous reportiez seulement les information essentielles et pertinentes,
et qu'elles soient clairement expliquées et organizées (e.g., on fait rappel que les graphiques doivent reporter
les label sur les axes, ainsi que l'unité de mesure correspondantes, etc.).

Dans ce TP, il s'agit d'étudier le comportement des protocoles TCP et UDP en utilisant le
simulateur NS2 (disponible à parir des ressources), qui utilise un langage simple pour la
description physique et comportementale des réseaux. Pour plus d'informations sur NS2, cfr:
http://www.isi.edu/nsnam/ns ou le tutoriel: http://www.isi.edu/nsnam/ns/tutorial/ (toutefois,
ces liens ne devraient pas être d'une utilité primordiale pour ce TP). Pour visualiser vos
courbes, vous pouvez utiliser Excel, Matlab, ou gnuplot (voir ressources).

1. Premier pas avec ns2

Afin de vous familiariser avec ce langage, nous avons détaillé le script correspondant au
fichier fenetre.tcl. L'exécution de NS présente une interface où vous pouvez taper une suite
de commandes interprétées. Vous devez taper source fenetre.tcl pour simuler le réseau décrit
par le script fenetre.tcl.

# Les instructions suivies du caractère # sont des commentaires 
# Initialisation du simulateur 
set ns [new Simulator] 

# Création de fichiers de traces 
set ftrace [open fout.tr w] 
set nf [open out.nam w] 

# traces animées 
$ns namtrace­all $nf 

# Procédure fermant les fichiers de traces 
proc finish {} { 
global ns ftrace nf 
$ns flush­trace 
close $nf 
close $ftrace 
exit 0 
} 

# Procédure permettant d'obtenir la taille de la fenêtre de congestion 
# toutes les 0.01s 

proc tracefenetre {} { 
global tcp0 ftrace 
set ns [Simulator instance] 
set time 0.01 
set now [$ns now] 
puts $ftrace "$now [$tcp0 set cwnd_]" 
$ns at [expr $now+$time] "tracefenetre" 
} 

# Initialisation de certains paramètres TCP 

# Taille des paquets TCP, en octets 
Agent/TCP set packetSize_ 1500 

# Taille maximale de la fenêtre de congestion, en paquets 
Agent/TCP set maxcwnd_ 30 

Agent/TCPSink/DelAck set interval_ 0.00001 

# Création du noeud  n0 et de ses caractéristiques 
# les connexions TCP étant unidirectionnelles, il y a une source et un puits par connexion 

# Création du noeud n0 
set n0 [$ns node] 

# Création de la couche TCP (agent TCP), côté source 
set tcp0 [new Agent/TCP] 

# Attachement de la couche TCP au noeud 
$ns attach­agent $n0 $tcp0 

# Création de la couche applicative FTP 
set ftp [new Application/FTP] 

# Attachement de la couche applicative à la couche TCP 
$ftp attach­agent $tcp0 

# Création du noeud n1 
set n1 [$ns node] 

# Création de la couche TCP, côté puits 
set tcp1 [new Agent/TCPSink/DelAck] 
# Attachement de la couche TCP au noeud 
$ns attach­agent $n1 $tcp1 

# Création du lien point­à­point bidirectionnel entre les deux noeuds 
# Le débit du lien est de 10Mb/s et le délai de propagation est de 10ms 
$ns duplex­link $n0 $n1 10Mb 10ms DropTail 

# Création de la connexion entre les deux couches TCP 
$ns connect $tcp0 $tcp1 

# Départ de la source FTP à la date 0.0 s 
$ns at 0.0 "$ftp start"" 

# Arrêt de la source FTP à la date 0.7 s 
$ns at 0.7 "$ftp stop" 

# Exécution de la procédure tracefenetre 
$ns at 0.0 "tracefenetre" 

# Exécution de la procédure finish à la date 0.8 s 
$ns at 0.8 "finish" 

# Exécution de la simulation 
$ns run 
  

Le script fenetre.tcl décrit une topologie de réseau constituée de deux noeuds (machines)
reliés en point-à-point et un comportement correspondant à l'ouverture d'une connexion TCP
et au transport d'un flux FTP jusqu'à la date t = 0,7 s. (Note: Le fichier d'animation out.nam
généré par ce script est consultable à l'aide du logiciel NAM)

2. Etude du comportement de la fenêtre de congestion

2.1) Tracez la courbe représentant la taille de fenêtre de congestion de l'émetteur en fonction

du temps, utilisez pour cela le fichier fout.tr obtenu par le traitement du script fenetre.tcl par
ns2 (le script fenetre.tcl considère un cas sans perte). Interprétez cette courbe.

2.2) Le script paquet.tcl décrit une topologie similaire à la précédente, seuls quelques
paramètres diffèrent. Il contient une procédure permettant d'obtenir le fichier pout.tr
contenant le nombre de paquets acquittés par le récepteur en fonction du temps.

• 2.2a)
Modifiez le script paquet.tcl pour obtenir les débits moyens (unité en Mb/s) de
réception du flux FTP pour des tailles maximales de la fenêtre de congestion de : 1, 5,
10, 25, 50, 100 paquets. À partir de ces valeurs tracez la courbe représentant le débit
moyen (unité en Mb/s) de réception du flux FTP en fonction de la taille maximale de
la fenêtre de congestion.
• 2.2b)
Modifiez le script paquet.tcl pour obtenir les débits moyens (unité en Mb/s) de
réception du flux FTP pour des délais de propagation de 1, 5, 10, 25, 50, 100 ms. À
partir de ces valeurs, tracez la courbe représentant le débit moyen (unité en Mb/s) de
réception du flux FTP en fonction du délai aller-et-retour.

Commentez les courbes obtenues. Ces courbes étaient-elles prévisibles ? Pouvez-vous définir
une formule générale (dans le cas où il n'y a pas de perte) du débit moyen de réception en
fonction de la taille maximale de la fenêtre de congestion, du délai aller-et-retour et du débit
du lien ?

2.3) La valeur la plus couramment utilisée pour la taille maximale de la fenêtre de

congestion est de 65 ko, qu'en déduisez-vous des performances de TCP sur un réseau haut-
débit? Pour cette réflexion, vous pouvez prendre l'exemple du réseau s'étendant sur 2000 km
de débit à 155,5 Mb/s et vitesse de propagation de 200 000 km/s (à noter que les délais de
transmission peuvent être considérés comme négligeables). Que faut-il faire pour résoudre le
problème ?

2.4) Le script fenetre-error.tcl décrit la topologie représentée par la figure 1. Cette

topologie comprend une station source, un routeur et une station destination. Le routeur joue
le rôle de goulot d'étranglement. Tracez la courbe représentant la taille de la fenêtre de
congestion de l'émetteur en fonction du temps. Interprétez cette courbe.

Figure 1 - Topologie1

3. Partage des ressources

Afin d'étudier le comportement du partage des ressources de TCP, nous allons simuler le
réseau représenté dans la figure 2. Il est constitué de 4 stations (A, A', B et B') reliés par un
lien à 10 Mb/s. Les délais de propagation séparant les stations au lien sont négligeables, par
contre le délai de propagation sur le lien est de 4 ms. Dans cette configuration, la ressource
partagée est le lien principal.

Figure 2 - Topologie2

3.1)
À la date t = 0 s, une connexion TCP est ouverte entre A et B pour transporter un flux FTP
continu. Ensuite, une connexion TCP est ouverte entre A' et B' pour transporter un flux FTP
qui stoppera avant la fin de simulation (la durée totale de simulation est de 10 s).
Simulez ce réseau à l'aide du fichier busTCP.tcl que vous devrez modifier pour obtenir
comme output un fichier contenant le nombre de paquets reçus pour les deux connexions
TCP (Si vous voulez visualiser les résultats grâce à NAM, vous remarquerez qu'une couleur
est associé à chaque flux). Tracez et interprétez la courbe du débit instantané des deux
connexions TCP. Que pourrait-on en conclure sur le partage des ressources entre deux flux
TCP ?

3.2)
Le flux TCP de A' vers B' est remplacé par un flux TFTP (utilisation de la couche UDP). Pour
le simulateur NS, l'agent UDP est incompatible avec l'application de type FTP. De ce fait,
l'application FTP est remplacée par une source constante, ce qui revient au même puisque la
couche UDP n'a aucune influence sur le débit des applications.
Simulez ce réseau à l'aide du fichier busUDP.tcl pour obtenir la courbe du débit instantané
du flux UDP (pour UDP le fichier pout.tr contient le nombre de datagrammes envoyés et non
pas reçus) et de la connexion TCP. Modifiez le script afin de visualiser la taille de la fenêtre
de congestion pour la connexion TCP. Commentez les courbes. Que peut-on en conclure sur
le partage des ressources entre un flux TCP et UDP ?

3.3)
On reprend la même topologie que le premier scénario, à ceci près que le délai de propagation
entre A' et B' est augmenté de 40 ms. Modifiez le fichier busTCP.tcl pour simuler ce nouveau
réseau et déduisez la courbe des débits des deux connexions TCP. Commentez les courbes.
Que peut-on en conclure sur le partage des ressources entre deux flux TCP dont les délais de
propagation diffèrent ?