Travaux Pratiques Network Simulator 2 (NS-2)

Transcription

1 1. Introduction Générale M2 - ASTR Année Réseaux et Commande (EIAASTAM) semestre 1 Travaux Pratiques Network Simulator 2 (NS-2) L Internet est en train de devenir le réseau universel pour tous les types de données, du transfert simple de fichiers binaires jusqu à la transmission de la voix, de la vidéo ou d informations interactives en temps réel. De plus, l Internet croît très rapidement, en taille (nombre d utilisateurs, d ordinateurs connectés, etc.) et en complexité, en particulier à cause de la nécessité d offrir de nouveaux services et d optimiser l utilisation des ressources de communication pour améliorer la Qualité de Service (QdS) offerte aux utilisateurs. La robustesse de l Internet d aujourd hui dépend fortement du mécanisme de contrôle de congestion de TCP (Transmission Control Protocol). Cependant, due à la grande variabilité des types de données et donc des applications déployées sur l Internet, il n est pas pensable que l utilisateur créé/intègre lui-même le contrôle adéquat de congestion. Par conséquent, il existe un grand nombre de mécanismes de gestion active des files d attente appelés AQM (Active Queue Management). Ces techniques permettent d optimiser la gestion des files d attente des routeurs qui constituent le réseau. La gestion de file d attente active permet d améliorer les transferts de données en termes de délais, d utilisation de liens, de bande passante disponible, de taux de pertes de paquets et d équité du système. Les trois séances de Travaux Pratiques sont à appréhender comme un seul mini-projet avec un but unique : gérer les files d'attentes d'un réseau sur lequel de nombreux flux circulent. Dans un premier temps, un réseau basique est simulé pour faciliter la prise en main du logiciel et des scripts permettant d'analyser le comportement des différentes applications et protocoles de Transport. Le réseau simulé sera ensuite modifié pour simuler un plus grand nombre de nœuds et de connexions. Enfin, plusieurs méthodes de gestion de files d'attente seront simulées et analysées. Ces méthodes devront être comparées entre elles et avec un mécanisme de gestion de files provenant de la théorie de la commande (correcteur PI). 1. Objectifs Séance n 1 : Prise en main de ns-2 et apprentissage à l analyse de résultats Dans cette première séance, vous allez découvrir ns-2 en simulant des réseaux simples. Vous apprendrez aussi comment exploiter les données générées par ns-2 afin de les rendre «lisibles». Les files d attente simulées dans ce TP seront de type DropTail. Plusieurs mesures permettent de connaitre l état d un réseau et le comportement des flux applicatifs dans ce réseau. Network Simulator génère des données brutes : les événements du réseau avec les dates de mise en attente, d émission, de suppression et de réception des différents paquets circulant sur le réseau simulé. Différents scripts vous sont fournis pour transformer ces données brutes en mesures compréhensibles et similaires aux mesures que l on pourrait obtenir dans la réalité. Pour chaque simulation, vous devrez observer les mesures suivantes : Travaux Pratiques M2 ASTR - UE RC - 1

2 Le délai de bout-en-bout pour chaque flux : temps écoulé entre la première mise en attente et la dernière réception de chaque paquet, Le débit de chaque flux à un certain point (l arrivée de préférence) : somme de la quantité de données reçues divisée par la durée d observation (granularité), Les statistiques de la file d attente au niveau du goulet d étranglement : sa taille, le nombre de pertes, le taux de pertes, Pour les flux TCP, la fenêtre de congestion de chaque flux : récupérée directement pas ns. Ces valeurs sont à observer dans ce TP, mais aussi dans les suivants. Dans la dernière partie de cette première séance de TP, vous devrez simuler un nombre conséquent d émetteurs et il faudra donc interpréter une grande quantité de mesures. Vous devrez alors définir une méthode pour analyser le comportement des flux grâce à ces mesures et qui permette d obtenir des données «lisibles». 2. Simulation d une communication entre deux nœuds Le premier réseau à simuler est représenté sur la Figure 1. Il est composé des deux nœuds connectés par une liaison full-duplex. Les caractéristiques du lien sont les suivantes : Bande passante : 1MBps, Délai : 20ms, File d attente : DropTail. La taille de la file ne sera pas précisée, ns-2 1 utilisera la taille par défaut. Ce réseau est proche de l exemple présenté en fin de cours. Servez-vous de cet exemple pour écrire le script de simulation à partir du fichier squelette.tcl qui vous est fourni (voir Annexe II). Des exemples de commandes pour traiter les données sont aussi fournis et vous pouvez vous référer aux entêtes des fichiers *.pl qui contiennent des explications sur le fonctionnement des scripts ainsi que les paramètres à fournir. Figure 1 Réseau simple composé de deux nœuds. 1. Dans un premier temps, vous allez simuler un unique flux TCP entre les deux nœuds. La durée de la simulation sera de 30 secondes, le flux devra démarrer à t=5s et se terminer à t=25s. Lancez ns en donnant en paramètre le script à simuler. Une fois la simulation terminée, vous pouvez lancer nam 2 pour visualiser le réseau et les flux qui y circulent. 2. Utilisez les scripts Perl 3 debit.pl et delai.pl pour calculer le débit du flux et le délai subi par les paquets. Les paramètres à passer aux scripts sont : le fichier de données, le nœud source, le nœud destination, la granularité pour le débit uniquement et le protocole du flux. Les valeurs calculées sont envoyées sur l affichage standard et peuvent être redirigées vers un fichier. Les données générées ont un format en colonnes avec la date dans la première colonne et les valeurs dans les colonnes suivantes. 1 ns-2 est utilisé en version Le paquetage allinone est disponible sur 2 Network ANimator (NAM) est inclus dans le paquetage allinone 3 Perl est disponible sur Travaux Pratiques M2 ASTR - UE RC - 2

3 3. Vous pouvez maintenant tracer des mesures à l aide de gnuplot 4. Gnuplot prend en paramètres : le fichier à lire, les colonnes à tracer (abscisses: ordonnées), le titre de la courbe et enfin le style de tracé (courbes, points, couleur, épaisseur, ). De la même manière, vous pouvez aussi afficher la taille de la file d attente et la fenêtre de congestion. Le cadre ci-dessous contient un exemple des commandes à lancer. Commandes à rentrer dans un terminal : ns tp1.tcl./debit.pl out.tr tcp > debit.dat./delai.pl out.tr tcp > delai.dat plot debit.dat using ($1) :($2) title TCP with lines lc 1 lw 2 4. Le débit et le délai permettent d illustrer les performances d une application. En vous basant sur vos observations, que pouvez-vous conclure sur cette communication. 5. Que pouvez-vous dire sur TCP lorsqu il est seul sur le réseau? Le comportement de TCP vous parait-il conforme à la théorie? Quelles phases pouvez-vous distinguer sur les graphes? Maintenant que vous savez analyser les données générées par ns-2, vous allez modifier le script de simulation pour ajouter un flux UDP. Ce flux commencera à t=10s et se terminera à t=20s. Enfin, vous pouvez remplacer ce flux UDP par un second flux TCP, changer la durée de simulation et les dates de début et de fin. 6. Quel est le comportement de TCP en présence d autres flux? Les valeurs obtenues pour le débit et le délai vous semblent-elles logiques comparées aux valeurs choisies comme caractéristiques du réseau? Concluez en faisant une synthèse de vos observations. 3. Simulation d un réseau simple Figure 2 Réseau composé de deux émetteurs et d un récepteur. Le réseau simulé dans cette partie comporte deux émetteurs distincts et un seul récepteur (voir Figure 2). Les chemins entre les émetteurs et le récepteur ne sont pas disjoints ; les deux émetteurs étant connectés au même routeur. Dans un tel réseau, une congestion peut apparaitre au niveau du routeur si la somme de la bande passante des deux premiers liens est supérieure à la bande passante entre le routeur et le récepteur. Le routeur agit alors comme un goulet d étranglement. Cette congestion peut être observée de différentes manières : 4 Gnuplot est disponible sur Travaux Pratiques M2 ASTR - UE RC - 3

4 Comportement instable des communications (débit, délai, gigue, ), Réactions de la congestion par la fenêtre de congestion des flux TCP, File d attente du routeur saturé. Ces différents phénomènes vont être observés dans cette partie du TP. Vous devrez les interpréter pour comprendre quelle est la réaction de TCP face à cette situation et quelles en sont les conséquences sur le réseau ainsi que sur les communications. Dans un premier temps, utilisez les caractéristiques suivantes pour simuler le réseau : Bande passante des liens entre les émetteurs et le routeur : 1MBps, Bande passante du lien entre le routeur et le récepteur : à déterminer, Délai sur chaque lien : 20ms, Politique de files d attente : DropTail. 1. Quelle valeur doit avoir la bande passante entre le routeur et le récepteur pour qu une congestion apparaisse au niveau du routeur? 2. Faites la simulation de ce réseau et analysez les résultats obtenus. Quelles sont les différences par rapport au premier réseau simulé? Comment pouvez-vous vérifier de manière pratique que la congestion du réseau est due au goulet d étranglement? 3. Changez la bande passante du lien routeur-récepteur et commentez les résultats. Quelle valeur minimale faut-il prendre pour que le débit soit uniquement limité par les liens en amont? 4. Les fluctuations des différents paramètres observés sont dues à des remplissages et des débordements de buffer dans le routeur. Augmentez puis diminuez le niveau maximum de la file d'attente et observez l impact sur les flux. Que pouvez-vous conclure de cette solution? 4. Configuration de manière itérative Dans les séances suivantes, il faudra être en mesure de simuler un grand nombre de nœuds et de flux (cf Figure 3). Dans cette configuration, chaque nœud rajouté est connecté au routeur et émet un flux TCP. Pour atteindre cet objectif de simulation, vous devez modifier votre script pour que la création du réseau et le paramétrage des protocoles se fasse de manière itérative ; i.e. l'utilisateur rentre uniquement le nombre de nœuds souhaités. Vous pouvez vous inspirer de l exemple donné dans le cours. Les nœuds routeur et récepteur étant identifiés respectivement comme 0 et 1, vous utiliserez des numéros de port commençant à Les sources seront donc , Travaux Pratiques M2 ASTR - UE RC - 4

5 Figure 3 Réseau composé de N émetteurs et d un seul récepteur. 1. Modifiez le script de simulation et testez-le avec 2 nœuds émettant des flux TCP et comparez avec l expérience précédente. Observez-vous des différences? 2. Recommencez la simulation avec plus de 2 nœuds (5, 10, 20, ) et analysez les résultats. Dans un tel contexte, une observation de chaque flux devient rapidement complexe : 20 flux à observer avec 4 ou 5 mesures par flux L affichage de toutes les données en même temps reste possible, mais peut être difficilement lisible. 3. Expliquez quelle méthode vous utiliseriez pour analyser ces résultats et observer le comportement des flux sur le réseau? Justifiez vos choix et vérifiez-les par la pratique. 5. Conclusion Synthétisez les observations que vous avez faites au cours de cette séance. Votre attention a du normalement se porter sur le comportement de TCP lorsqu il y a de la congestion dans le réseau et sur l impact de la politique de file d attente DropTail. L analyse de cette première séance doit vous permettre de préparer au mieux la séance suivante. Séance n 2 : Comparaison de différentes files 1. Rappels et Objectifs Nous avons vu dans le TP précédent que la taille de la file d'attente avait un impact fort sur les communications. La politique DropTail utilisée est la plus simple qui existe, lorsque la file est pleine, elle refuse les nouveaux paquets et/ou supprime les derniers ajoutés. Network Simulator propose l'utilisation de différentes politiques de files d'attentes dans les liens terrestres : Random Early Discard (RED) : les paquets sont supprimés suivant une certaine probabilité. Cette probabilité augmente entre deux seuils définis par l'utilisateur. Deficit Round Robin (DRR) : un file d attente par flux est crée et un ordonnanceur pioche dans les files une après les autres, Stochastic Fair Queuing (SFQ) : implémentation de l algorithme Fair Queuing, Class-Based Queuing (CBQ) : différencie les flux suivant leur classe (flow id), Des paramètres peuvent modifier le comportement des files, par exemple DropFront : Lorsque la file est pleine, les paquets les plus anciens sont supprimés, Les précisions nécessaires à l utilisation des ces politiques de file d attente sont détaillées en Annexe avec un extrait du manuel de ns-2. Pour plus de détails sur le fonctionnement ou sur les paramètres Travaux Pratiques M2 ASTR - UE RC - 5

6 de ces files, vous pouvez regarder les fichiers sources dans «ns/queue/» ou le fichier contenant les valeurs par défaut prises par ns dans «ns/tcl/lib». Le réseau simulé dans cette séance possède les caractéristiques suivantes : Nombre de nœuds émetteurs : 20, Durée totale de la simulation 200 secondes, Taille maximale de la file d attente dans le routeur : 200 paquets, Bande passante du lien routeur-récepteur : 10Mbps. 1. Les politiques testées dans cette séance seront comparés celle utilisée dans la première séance : DropTail. Reprenez votre précédent script, modifiez le et faites une simulation. Observez les résultats et sauvegardez-les pour pouvoir y revenir par la suite. 2. Random Early Discard Dans cette partie, vous allez mettre en place une politique RED dans la file d attente du routeur. Cette politique introduit une probabilité de supprimer un paquet suivant le niveau de la file d attente. Cette probabilité vaut 0 lorsque la file est vide. À partir d un seuil dit «minimal», cette probabilité augmente et atteint sa valeur maximale pour un seuil dit «maximal». Au delà du seuil maximal, la probabilité de suppression vaut 1. La Figure 4 présente l évolution de cette probabilité suivant la taille de la file d attente. Le réglage des divers paramètres (seuil minimum, seuil maximum, probabilité, ) peut être fait par l utilisateur même si ns comprend des valeurs par défaut. Les valeurs utilisées sont choisies en fonction : Du réseau où la file d attente est implémentée : dimensionnement, type de flux De la position du nœud dans ce réseau : routeur, points d accès, nœud utilisateur, Du comportement souhaité : délai faible, stabilité débit et/ou délai, débit important, Vous pouvez regarder l annexe ainsi que le code source de ns-2 pour déterminer sur quels facteurs vous allez agir et quels sont les noms des variables associés. Ouvrez «ns/tcl/lib/ns-default.tcl» pour trouver les valeurs par défaut d une file d attente RED. Les seuils sont réglés automatiquement si leur valeur n est pas spécifiée dans le script de simulation. Le réglage se fait en fonction de la bande passante du lien, de la taille moyenne des paquets et du temps de service souhaité. Travaux Pratiques M2 ASTR - UE RC - 6

7 Figure 4 - Probabilité de suppression d un paquet en fonction de la taille de la file. [1] [2] 1. Les équations [1] et [2] sont utilisées par ns-2 pour déterminer les valeurs des seuils de RED. Les paramètres targetdelay et meanpacketsize sont des paramètres de RED. En se basant sur les caractéristiques de notre réseau et sur les valeurs par défaut de ces deux paramètres, déterminez les valeurs utilisées par RED pour le seuil minimal et le seuil maximal. 2. Faites une première simulation en utilisant ces valeurs et analysez vos résultats. Quels commentaires pouvez-vous faire par rapport à la simulation précédente avec DropTail? Les gains obtenus vous semblent-ils satisfaisants? Pour quelle raisons? 3. Certains paramètres doivent être changés pour que la configuration de la file d attente soit en accord avec les caractéristiques du réseau et les flux présents. Quels sont ces paramètres et quelles doivent-elles être leurs valeurs? Refaites la simulation en réglant ces paramètres. Quels changements observez-vous? 4. Vous allez maintenant modifier les seuils pour qu il y ait moins de suppression de paquets dans le routeur. Quelles valeurs pouvez-vous prendre? Modifiez ces valeurs dans le script de simulation et refaites la simulation. Quel est l effet de ce changement sur les communications? Comment auriez-vous pu obtenir le même résultat sans régler directement les seuils? 3. Deficit Round Robin Dans cette partie, vous allez utiliser la politique de file d attente Deficit Round Robin implémentée dans ns-2. Cette politique consiste à différencier les flux et les stocker dans différentes files d attente. Les flux peuvent être différenciés suivant leur nœud et aussi leur port éventuellement. Une représentation est donnée par la Figure 5. Travaux Pratiques M2 ASTR - UE RC - 7

8 Figure 5 Illustration de la politique de file d attente Deficit Round Robin Le Round Robin consiste à parcourir des files d attente et à les servir une après les autres. Les Deficit Round Robin utilise un quantum pour déterminer la quantité de données qui peut être envoyée à chaque cycle. Si le quantum n est pas consommé entièrement, un compteur déficitaire enregistre la différence entre la valeur du quantum et la quantité de données envoyées. Les réactions suivant les données contenues par les files sont donc les suivantes : Paquets en attente de taille inférieure au quantum : une quantité de donnée égale ou inférieur au quantum peut être envoyée et le compteur enregistre la différence. Paquets en attente de taille supérieure au quantum : rien n est envoyé et le compteur est incrémenté de la valeur du quantum. Pas de paquets en attente : le quantum n est pas utilisé mais le compteur est mis à 0. Lors du cycle suivant, la valeur du compteur est ajoutée au quantum pour permettre l envoi de paquets de plus grande taille ou la récupération de la part du quantum précédent non-utilisée. Avec ns-2, l utilisateur peut régler la valeur du quantum, le nombre de files (buckets) et la taille totale de la file d attente. Comme pour RED, des détails sur DRR et sur les paramètres à utiliser sont donnés en Annexe. Les valeurs pas défaut sont stockés dans le même fichier «ns/tcl/lib/ns-default.tcl». 1. Effectuez une simulation sur le réseau précédent avec une politique DRR dans le routeur. Que constatez-vous sur le comportement des flux? 2. Comparez ces résultats avec ceux obtenus précédemment avec DropTail et RED. Quelle politique vous semble la plus performante et pourquoi? Le comportement du réseau vous semble-t-il plus proche des simulations faites avec DropTail ou avec RED? 3. Le Round Robin étant basé sur un principe simple ; le service de chaque file successivement. Par exemple, le Weighted Round Robin permet de mettre un poids à chaque file d attente et de les servir suivant ce poids. Quel peut-être l intérêt d une telle politique? Donnez un exemple d une situation où cette file améliorerait les performances du réseau ou des applications. Facultatif : Vous pouvez simuler les autres politiques de files d attente présentes en Annexe et implémentées dans ns-2. Quelle politiques vous paraissent adaptées au réseau simulé? Travaux Pratiques M2 ASTR - UE RC - 8

9 4. Conclusion Faites une synthèse des travaux faits pendant ces deux premières séances. Vous devrez expliquer l impact des politiques de file d attente sur le réseau en vous basant sur l analyse de vos simulations. Cette conclusion doit vous permettre de préparer la troisième et dernière séance appliquée aux outils de l Automatique pour la QdS d un réseau de communication. Travaux Pratiques M2 ASTR - UE RC - 9

10 Annexe I Extrait du manuel de ns-2 (partie 7.3) Different types of Queue objects A queue object is a general class of object capable of holding and possibly marking or discarding packets as they travel through the simulated topology. Configuration Parameters used for queue objects are : limit_ The queue size in packets, blocked_ Set to false by default, this is true if the queue is blocked (unable to send a packet to its downstream neighbor). unblock_on_resume_ Set to true by default, indicates a queue should unblock itself at the time the last packet packet sent has been transmitted (but not necessarily received). Other queue objects derived from the base class Queue are drop-tail, FQ, SFQ, DRR, RED and CBQ queue objects. Each are described as follows : Drop-tail objects : Drop-tail objects are a subclass of Queue objects that implement simple FIFO queue. There are no methods, configuration parameter, or state variables that are specific to drop-tail objects. FQ objects : FQ objects are a subclass of Queue objects that implement Fair queuing. There are no methods that are specific to FQ objects. Configuration Parameters are : secsperbyte_ There are no state variables associated with this object. SFQ objects : SFQ objects are a subclass of Queue objects that implement Stochastic Fair queuing. There are no methods that are specific to SFQ objects. Configuration Parameters are : maxqueue_ buckets_ There are no state variables associated with this object. DRR objects : DRR objects are a subclass of Queue objects that implement deficit round robin scheduling. These objects implement deficit round robin scheduling amongst different flows ( A particular flow is one which has packets with the same node and port id OR packets which have the same node id alone). Also unlike other multi-queue objects, this queue object implements a single shared buffer space for its different flows. Configuration Parameters are : buckets_ Indicates the total number of buckets to be used for hashing each of the flows. blimit_ Indicates the shared buffer size in bytes. quantum_ Indicates (in bytes) how much each flow can send during its turn. mask_ when set to 1, means that a particular flow consists of packets having the same node id (and possibly different port ids), otherwise a flow consists of packets having the same node and port ids. RED objects : RED objects are a subclass of Queue objects that implement random early-detection gateways. The object can be configured to either drop or mark packets. There are no methods that are specific to RED objects. Configuration Parameters are : Travaux Pratiques M2 ASTR - UE RC - 10

11 bytes_ Set to "true" to enable byte-mode RED, where the size of arriving packets affect the likelihood of marking (dropping) packets. queue-in-bytes_ Set to "true" to measure the average queue size in bytes rather than packets. Enabling this option also causes thresh_ and maxthresh_ to be automatically scaled by mean_pktsize_ (see below). thresh_ The minimum threshold for the average queue size in packets. maxthresh_ The maximum threshold for the average queue size in packets. mean_pktsize_ A rough estimate of the average packet size in bytes. Used in updating the calculated average queue size after an idle period. q_weight_ The queue weight, used in the exponential-weightedmoving average for calculating the average queue size. wait_ Set to true to maintain an interval between dropped packets. linterm_ As the average queue size varies between "thresh_" and "maxthresh_", the packet dropping probability varies between 0 and "1/linterm". setbit_ Set to "true" to mark packets by setting the congestion indication bit in packet headers rather than drop packets. drop-tail_ Set to true to use drop-tail rather than randomdrop when the queue overflows or the average queue size exceeds "maxthresh_". None of the state variables of the RED implementation are accessible. CBQ objects : CBQ objects are a subclass of Queue objects that implement class-based queueing. $cbq insert <class> Insert traffic class class into the link-sharing structure associated with link object cbq. $cbq bind <cbqclass> <id1> [$id2] Cause packets containing flow id id1 (or those in the range id1 to id2 inclusive) to be associated with the traffic class cbqclass. $cbq algorithm <alg> Select the CBQ internal algorithm. <alg> may be set to one of: "ancestor-only", "top-level", or "formal". CBQ/WRR objects : CBQ/WRR objects are a subclass of CBQ objects that implement weighted round-robin scheduling among classes of the same priority level. In contrast, CBQ objects implement packet-by-packet round-robin scheduling among classes of the same priority level. Configuration Parameters are : maxpkt_ The maximum size of a packet in bytes. This is used only by CBQ/WRR objects in computing maximum bandwidth allocations for the weighted round-robin scheduler. Travaux Pratiques M2 ASTR - UE RC - 11

12 Annexe II Squelette du script de simulation en TCL # Squelette de script de simulation ns-2 puts "lancement de squelette.tcl" # instance du simulateur set ns [new Simulator] # # Configuration de NS : # - ouverture des fichiers trace, # - création de variables. # ouverture des fichiers trace # trace des evenements réseaux set ns_file [open "out.tr" w] $ns trace-all $ns_file # trace utilisée par nam set nam_file [open "out.nam" w] $ns namtrace-all $nam_file # Couleur utilisée par nam suivant le flow ID $ns color 0 Blue $ns color 1 Red # création du fichier pour enregistrer la fenetre de congestion set winfile [open WinFile.tr w] # création du fichier pour enregistrer les statistiques sur une file set q_stat [open queue_stat.tr w] # intervalle entre 2 mesures de la fenetre de congestion set intervalle 0.1 # intervalle entre 2 stats sur la file set intervalle_queue 0.2 # durée de la simulation set Duration 50 # # Configuration des differentes classes : # Classe_mere/Classe_fille set parametre valeur # A COMPLETER!!! # # # Création des éléments simulant le réseau : # - Noeuds, # - Liens. # A COMPLETER!!! # Travaux Pratiques M2 ASTR - UE RC - 12

13 # # Création des connexions : # - agent source, # - agent puit, # - attachement de chaque agent à un noeud, # - Lien entre les deux. # A COMPLETER!!! # # # Affichage d'informations (Facultatif) # Objets contenus dans le classifier d'adresses du noeud : # [$noeud set classifier] dump # Objets contenus dans le classifier de port de noeud : # [$noeud set dmux_] dump # # Configuration d'un moniteur sur une file d'attente : # - Lien entre n0 et n1, # - Enregistrement dans queue.tr, # - Intervalle de set q_file [$ns monitor-queue $n0 $n1 [open queue.tr w] 0.005] [$ns link $n0 $n1] queue-sample-timeout # # Definition des procedures utilisées par le script : # - fin de la simulation, # - Enregistrement de la fenetre de congestion d'un flux tcp, # - Enregistrement de l'état d'une file d'attente. # Procedure permettant à ns de se terminer proc finish {} { global ns nam_file ns_file q_stat $ns flush-trace close $ns_file close $nam_file close $q_stat puts "Finished." exit 0 } # Procedure d'enregistrement de la fenetre de congestion # executée toutes les "intervalle" secondes proc plotwindow {tcpsource file} { global ns Duration intervalle set time $intervalle set now [$ns now] set cwnd [$tcpsource set cwnd_] if {$now <= $Duration} { puts $file "$now $cwnd" } $ns at [expr $now+$time ] "plotwindow $tcpsource $file" Travaux Pratiques M2 ASTR - UE RC - 13

14 } # Procedure d'enregistrement des statistiques de la file # exécutée toutes les "intervalle_queue" secondes proc record {} { global ns q_stat n0 n1 q_file intervalle_queue set time $intervalle_queue set now [$ns now] set compt 0.0 $q_file instvar parrivals_ pdepartures_ bdrops_ bdepartures_ pdrops_ pkts_ size_ # ecriture dans le fichier : taille, bw, loss, pkt pass puts $q_stat "$now [expr $pkts_] [expr $bdepartures_*8/1024/$time] [expr $pdrops_] [expr $pdepartures_] [expr $size_] [expr $pdepartures_] [expr $parrivals_]" set bdepartures_ 0 $ns at [expr $now+$time] "record" } # # Parametrage des divers évènements de la simulation: # - Lancement des procedures d'enregistrement (avec arguments si besoin), # - Configuration des dates de début et de fin des communications, # - Définition de la date de fin de la simulation, # - Lancement de la simulation. # Definition des evenements : $ns at date "commande" # A COMPLETER!!! # Travaux Pratiques M2 ASTR - UE RC - 14