MEZIANE Wiame JIBBAWI Ali RAJAONARIVONY Njary

Rapport de TP Rseaux : Couche Transport TCP/UDP

2. Etude du comportement de la fentre de congestion

2.1. Courbe reprsentant la taille de fentre de congestion de l'metteur
Sur la figure1 on visualise la courbe reprsentant la taille de la fentre de congestion de l'metteur en fonction du temps en utilisant le fichier fout.tr obtenu par le traitement du script fenetre.tcl par ns2.

Figure 1

Interprtation :
Laxe des abscisses reprsente le temps (en secondes s), celui des ordonnes reprsente la congestion en paquets, sachant que 1paquet est gale 1500octets Sur la courbe obtenue on relve trois phases distinctes sur trois intervalles de temps : Phase 1 : Slow-start [0<t<0.11s] Lallure de la courbe est exponentielle. Car, on augmente les paquets mis c'est dire l'augmentation de la taille de la fentre de congestion : Au dbut de lmission on commence par mettre un seul segment car la fentre cwnd est initialise 1mss, puis la rception de chaque acquittement, la fentre de la taille de congestion augmente de la manire suivante : A la rception dun acquittement on se permet denvoyer un mss de plus, ce qui implique que le nombre de paquets envoys se double chaque RTT do lallure exponentielle. Phase2: Congestion avoidance [0.11s<t<0.44s] vgDans cette phase la courbe est linaire en fonction du temps. A chaque RTT on envoie un paquet de plus car dans cette phase TCP se comporte de la faon suivante :

 La rception de chaque acquittement permet l'augmentation de la taille de la fentre de congestion de 1/x, o x reprsente la taille de la fentre de congestion. Ce qui est du au fait que le ss_thres a t fix 20. Phase3: [t>0.44s] Cest la phase o la courbe a une forme de dents de scie, qui est due au fait que la fentre de congestion ne peut dpasser maxcwnd qui est fix 30 segments : chaque fois que lmetteur vrifie quon a dpass 30, il remet la taille de la fentre 30.

2.2. Dbit moyen

2.2.a Calcul du dbit moyen de rception du flux FTP pour des fentres max diffrentes Dans le script paquet.tcl on modifie le paramtre maxcwnd qui reprsente la taille maximale de la fentre de congestion, en lui attribuant successivement diffrentes valeurs reprsentes dans le tableau1. A partir de ces valeurs on trace la courbe (figure2) reprsentant le dbit moyen de rception du flux FTP en fonction de la taille maximale de la fentre de congestion.

Cwnd
1 5 10 15 25 30
Tableau 1

Dbit (Mb/s)
0,5616 2,7984 5,5704 8,3304 9,8184 9 ,8184

Figure 2

Durant la premire phase, on remarque que le dbit augmente avec la fentre de congestion. En effet, nous pouvons mettre plus de paquets au fur et mesure que la taille de la fentre augmente. La deuxime phase est caractrise par une stabilisation du dbit. Cela est du au fait que le dbit moyen du lien est fix 10Mb/s. (cest la limite de la bande passante) 2.2.b Calcul du dbit moyen de rception du flux FTP pour des dlai de propagation diffrentes Dans cette question, on va tudier lvolution du dbit effectif du canal en fonction du temps de propagation, pour cela on fait varier ce dernier tout en gardant les mmes valeurs pour la taille de la fentre de congestion qui est fix a 30 paquets et le dbit maximal du canal qui est fix 10Mbps. On sait que : RTT=Temps de transmission+ 2* dlai de propagation Temps de transmission : longueur du paquet/dbit = 1500*8/10000000=1,2ms Le tableau2 reprsente les variations du dbit effectif en fonction du temps de propagation.

RTT(ms)
6,2 11,2 31,2 61,2 81,2
Tableau 2

Dbit (Mb/s)
9,96 2,9216 5,6184 2,8056 2,0856

On obtient le graphe suivant :

Figure 3

Interprtation :
La courbe ci-dessus trace lvolution du dbit en fonction du RTT. On remarque daprs le graphe, que dans un premier temps le dbit effectif du canal reste constant sur un seuil 9.5 Mbps, limit par le dbit maximal qui est de 10 Mbps. Dans ce cas le temps de propagation reste ngligeable et na donc aucun effet sur ce dernier. Dans un second temps ( partir dun temps de propagation de lordre de 10 ms), nous constatons quil y a diminution du dbit effectif avec laugmentation du temps de propagation. En effet, le temps de propagation de A vers B est fonction de la vitesse de propagation et de la distance entre A et B. Le dbit effectif du canal est ainsi fonction de linverse du temps de propagation, ce qui explique lallure obtenue.

Formule gnrale :
A partir du graphe de 2.1 la relation entre Dbit moyen et Cwnd est linaire donc on peut crire la fonction du dbit moyen qui est donc : DM = K1* Cwnd (avec k1 constante) / sachant que DM DL (1) DM= K2/RTT / sachant que DM DL (2) De (1) et (2)

DM = min [ (Cwnd * k)/RTT, DL ] 2.3. La valeur la plus couramment utilise pour la taille maximale de la fentre tant 65ko.
Les donnes sont : La taille maximale de la fentre de congestion est de Maxcwnd_=65ko En terme de paquets c'est : (65*1000)/1500=44,3 paquets, La distance entre les deux machines est de d=2000 Km La vitesse de propagation de v=200000 Km/s. Le dbit de D=155,5 Mbps. avec la simulation on obtient un dbit moyen de Dmoy=11,15 Mbps. Si on fait le calcul du dbit du throughput en supposant que le temps pour rpondre avec un acquittement chez le rcepteur est nul on aura. Debit= 65000*8/(65000*8/155.5*10^6+0.02)= 22.3 Mbps

On obtient un dlai de propagation de T=d/v=10ms. On peut remarquer donc que Dmoy de simulation=11.15Mbps<throughput<D=155.5Mbps, ce qui montre bien que les connexions TCP limitent le dbit effectif. Ceci est d la limitation du nombre de paquets transmis avant de recevoir leurs acquittements. Ainsi si le contrle de flux est fiable dans les communications TCP, il reprsente par contre un rel handicap pour le dbit.

Solutions proposes :
Les Options TCP permettent de rajouter des possibilits supplmentaires non prvues dans l'entte de base et donc on peut les utiliser pour agrandir notre fentre de congestion maximale Soit on peut utiliser UDP si lapplication permet la perte.

2.4. La courbe reprsentant la taille de la fentre de congestion de lmetteur en fonction du temps.

Le script fenetre-error.tcl dcrit la topologie reprsente par la figure 1. Cette topologie comprend une station source, un routeur et une station destination. Le routeur joue le rle de goulot d'tranglement. Voici la courbe reprsentant la taille de la fentre de congestion de l'metteur en fonction du temps.

Figure 4

Interprtations :
Nous pouvons constater que l'tat initial de l'metteur est un slow start avec acquittements cumuls. Au bout de 530ms nous repassons en tat slow start. Le timer de retransmission a donc conclu une perte de segments. Cette perte est du au goulot dtranglement existant ; il y a beaucoup de paquets mis mais le dbit du deuxime lien est trs petit par rapport au dbit du premier lien ce qui implique une attente des paquets dans la file dattente de linterface dentre du routeur. Puisque cette file dattente n est pas infinie, un moment donn il ya des paquets qui vont tre purgs. Ainsi l'metteur recommence mettre en mode slow start mais dfinissant un nouveau seuil= cwnd/2, ici 21paquets. Sitt ce seuil atteint, il passe en mode congestion avoidance. Au bout de 300ms environ, le timer constate une perte de paquets pour la mme raison goulot dtranglement et donc l'metteur repasse en slow start en divisant encore sa fentre par deux. Ainsi il repart en slow start jusqu' atteindre le nouveau ss_thres (10) et passe en congestion avoidance.

3. Partage des ressources

Afin d'tudier le comportement du partage des ressources de TCP, nous allons simuler le rseau reprsent dans la figure 2. Il est constitu de 4 stations (A, A', B et B') relis par un lien 10 Mb/s. Les dlais de propagation sparant les stations au lien sont ngligeables, par contre le dlai de propagation sur le lien est de 4 ms. Dans cette configuration, la ressource partage est le lien principal.

3.1. Analyse de deux trafics TCP

Premier scnario la date t = 0 s, une connexion TCP est ouverte entre A et B pour transporter un flux FTP continu. la date t = 1 s, une connexion TCP est ouverte entre A' et B' pour transporter un flux FTP qui stoppera avant la fin de simulation (la dure totale de simulation est de 4 s). Aprs simulation du rseau l'aide du fichier busTCP.tcl, on obtient le fichier pout.tr contenant le nombre de paquets reus pour les deux connexions TCP:

Figure 5

Voici la courbe du dbit instantan des deux connexions TCP :

Figure 6

Nous remarquons sur la premire courbe que le nombre de paquets envoy sgalise ds que la deuxime connexion TCP est active (du au faite que la premire connexion dtecte une perte car il ya une autre qui met en mme temps, et donc les deux vont rgler cwnd dune faon ne plus perdre de paquets), un constat valid par la seconde courbe qui permet de dire quil y un partage de ressources quitable entre chaque connexion TCP, vu lgalit des dbits instantans des deux trafics. Deuxime scnario

Figure 7 le flux 2 represente le flux udp et le flux 1 represente le flux tcp. On remarque que le comportement de la connexion TCP est normale jusqu louverture dune connexion UDP ou on commence remarquer que le nombre de paquets envoys par UDP augmente normement au dtriment du flux TCP.

Interprtations :
UDP ne fait pas le contrle de congestion et donc il se permet denvoyer autant qu il veut et donc le nombre de paquets UDP augmente enormement et UDP ne remarque pas qu il y a des paquets perdus. Par contre TCP qui lui fait le contrle de congestion detecte quil a des paquets perdus, donc il rerduit son debit mais il remarque toujours qu il y a de perte car UDP a satur la bande et donc il a toujours son cwnd 1 et son debit est presque nul Remarque : le dbit instantan denvoi des paquets UDP est de 6000*1500*8=72Mbps, qui est beaucoup plus grand que la capacit relle du lien physique. On en conclut quil y aura certainement une perte de paquets ct reception.

Troisime scnario :

Figure 8 Avant que la connexion (A B) se lance, la connexion (A B) exploite toute la capacit de la liaison. Par contre, quand la connexion (A B) se lance, les deux connexions ne partage pas quitablement le rseau, mais le dbit de AB et plus grands que le dbit de AB parce que le dlai de propagation de AB est plus petit que le dlai de propagation de AB , car on est toujours oblige de recevoir les acquittements avant denvoyer ce qui tarde A envoyer et donc le dbit de la connexion AB est plus petit que celui de AB. A larrt de la connexion AB , la connexion AB reprend toute la capacit du rseau.