TP Pro Toc Oles de Tra-meziane_Rapport

5/17/2018 TP Pro Toc Oles de Tra-meziane_Rapport - slidepdf.com

http://slidepdf.com/reader/full/tp-pro-toc-oles-de-tra-mezianerapport 1/9

1MEZIANE Wiame

JIBBAWI Ali

RAJAONARIVONY Njary

Rapport de TP Réseaux : Couche Transport

TCP/UDP



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

2.1. Courbe représentant la taille de fenêtre de congestion de l'émetteur

Sur la figure1 on visualise la courbe représentant la taille de la fenêtre de congestionde l'émetteur en fonction du temps en utilisant le fichier fout.tr obtenu par le traitement duscript fenetre.tcl par ns2.

Figure 1

Interprétation :

L’axe des abscisses représente le temps (en secondes s), celui des ordonnées représente la

congestion en paquets, sachant que 1paquet est égale à 1500octets

Sur la courbe obtenue on relève trois phases distinctes sur trois intervalles de temps :

Phase 1 : Slow-start [0<t<0.11s]

L’allure de la courbe est exponentielle. Car, on augmente les paquets émis c'est à dire

l'augmentation de la taille de la fenêtre de congestion :Au début de l’émission on commence par émettre un seul segment car la fenêtre cwnd estinitialisée à 1mss, puis à la réception de chaque acquittement, la fenêtre de la taille decongestion augmente de la manière suivante :

A la réception d’un acquittement on se permet d’envoyer un mss de plus, ce quiimplique que le nombre de paquets envoyés se double à chaque RTT d’où l’allureexponentielle.

Phase2: Congestion avoidance [0.11s<t<0.44s]

vgDans cette phase la courbe est linéaire en fonction du temps. A chaque RTT on envoie unpaquet de plus car dans cette phase TCP se comporte de la façon suivante :



3 La réception de chaque acquittement permet l'augmentation de la taille de la fenêtre de

congestion de 1/x, où x représente la taille de la fenêtre de congestion. Ce qui est du aufait que le ss_thres a été fixé à 20.

Phase3: [t>0.44s]C’est la phase où la courbe a une forme de dents de scie, qui est due au fait que la fenêtre decongestion ne peut dépasser maxcwnd qui est fixé à 30 segments : à chaque fois quel’émetteur vérifie qu’on a dépassé 30, il remet la taille de la fenêtre à 30.

2.2. Débit moyen

2.2.a Calcul du débit moyen de réception du flux FTP pour des fenêtres max

différentes

Dans le script paquet.tcl on modifie le paramètre maxcwnd qui représente la taille maximalede la fenêtre de congestion, en lui attribuant successivement différentes valeurs représentéesdans le tableau1. A partir de ces valeurs on trace la courbe (figure2) représentant le débitmoyen de réception du flux FTP en fonction de la taille maximale de la fenêtre de congestion.

Tableau 1

Figure 2

Cwnd Débit (Mb/s)

1 0,5616

5 2,7984

10 5,5704

15 8,3304

25 9,8184

30 9 ,8184



4

Durant la première phase, on remarque que le débit augmente avec la fenêtre de congestion.En effet, nous pouvons émettre plus de paquets au fur et à mesure que la taille de la fenêtreaugmente.

La deuxième phase est caractérisée par une stabilisation du débit. Cela est du au fait que ledébit moyen du lien est fixé à 10Mb/s. (c’est la limite de la bande passante)

2.2.b Calcul du débit moyen de réception du flux FTP pour des délai de

propagation différentes

Dans cette question, on va étudier l’évolution du débit effectif du canal en fonction du tempsde propagation, pour cela on fait varier ce dernier tout en gardant les mêmes valeurs pour lataille de la fenêtre de congestion qui est fixé a 30 paquets et le débit maximal du canal qui estfixé à 10Mbps.On sait que :

RTT=Temps de transmission+ 2* délai de propagation Temps de transmission : longueur du paquet/débit = 1500*8/10000000=1,2ms

Le tableau2 représente les variations du débit effectif en fonction du temps de propagation.

Tableau 2

On obtient le graphe suivant :

Figure 3

RTT(ms) Débit (Mb/s)

6,2 9,96

11,2 2,9216

31,2 5,6184

61,2 2,8056

81,2 2,0856



5Interprétation :

La courbe ci-dessus trace l’évolution du débit en fonction du RTT.On remarque d’après le graphe, que dans un premier temps le débit effectif du canal reste

constant sur un seuil à 9.5 Mbps, limité par le débit maximal qui est de 10 Mbps. Dans ce casle temps de propagation reste négligeable et n’a donc aucun effet sur ce dernier.Dans un second temps (à partir d’un temps de propagation de l’ordre de 10 ms), nous

constatons qu’il y a diminution du débit effectif avec l’augmentation du temps de

propagation. En effet, le temps de propagation de A vers B est fonction de la vitesse depropagation et de la distance entre A et B. Le débit effectif du canal est ainsi fonction del’inverse du temps de propagation, ce qui explique l’allure obtenue.

Formule générale :

A partir du graphe de « 2.1 » la relation entre Débit moyen et Cwnd est linéaire donc on peutécrire la fonction du débit 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 utilisée pour la taille maximale de la

fenêtre étant 65ko.

Les données sont :

La taille maximale de la fenêtre 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 débit de D=155,5 Mbps.

avec la simulation on obtient un débit moyen de Dmoy=11,15 Mbps. Si on fait le calcul du débit du throughput en supposant que le temps pour répondre

avec un acquittement chez le récepteur est nul on aura. Debit= 65000*8/(65000*8/155.5*10^6+0.02)= 22.3 Mbps

On obtient un délai 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 débit effectif. Ceci est dû à lalimitation du nombre de paquets transmis avant de recevoir leurs acquittements. Ainsi si le

contrôle de flux est fiable dans les communications TCP, il représente par contre un réelhandicap pour le débit.



6Solutions proposées :

Les Options TCP permettent de rajouter des possibilités supplémentaires non prévuesdans l'entête de base et donc on peut les utiliser pour agrandir notre fenêtre decongestion maximale

Soit on peut utiliser UDP si l’application permet la perte.

2.4. La courbe représentant la taille de la fenêtre de congestion del’émetteur en fonction du temps.

Le script fenetre-error.tcl décrit la topologie représentée par la figure 1. Cette topologiecomprend une station source, un routeur et une station destination. Le routeur joue le rôle degoulot d'étranglement. Voici la courbe représentant la taille de la fenêtre de congestion del'émetteur en fonction du temps.

Figure 4

Interprétations :

Nous pouvons constater que l'état initial de l'émetteur est un slow start avec acquittementscumulés. Au bout de 530ms nous repassons en état slow start. Le timer de retransmission adonc conclu à une perte de segments. Cette perte est du au goulot d’étranglement existant ; ily a beaucoup de paquets émis mais le débit du deuxième lien est très petit par rapport audébit du premier lien ce qui implique une attente des paquets dans la file d’attente del’interface d’entrée du routeur.Puisque cette file d’attente n est pas infinie, à un moment donné il ya des paquets qui vont êtrepurgés. Ainsi l'émetteur recommence à émettre en mode slow start mais définissant unnouveau seuil= cwnd/2, ici 21paquets.Sitôt ce seuil atteint, il passe en mode congestion avoidance. Au bout de 300ms environ, letimer constate une perte de paquets pour la même raison ‘goulot d’étranglement’ et doncl'émetteur repasse en slow start en divisant encore sa fenêtre par deux. Ainsi il repart en slow

start jusqu'à atteindre le nouveau ss_thres (10) et passe en congestion avoidance.

http://www.infres.enst.fr/~boukhate/HTML/fenetre-error.tcl





73. Partage des ressources

Afin d'étudier le comportement du partage des ressources de TCP, nous allons simuler leré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, parcontre le délai de propagation sur le lien est de 4 ms. Dans cette configuration, la ressourcepartagée est le lien principal.

3.1. Analyse de deux trafics TCP

Premier scénario

À la date t = 0 s, une connexion TCP est ouverte entre A et B pour transporter un flux FTPcontinu. À 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 durée totale de simulation est de 4 s).Après simulation du réseau à l'aide du fichier busTCP.tcl, on obtient le fichier pout.trcontenant le nombre de paquets reçus pour les deux connexions TCP:

Figure 5

Voici la courbe du débit instantané des deux connexions TCP :

Figure 6

http://www.infres.enst.fr/~boukhate/HTML/busTCP.tcl





8 Nous remarquons sur la première courbe que le nombre de paquets envoyé s’égalise dès que la deuxième connexion TCP est activée (du au faite que la première connexion détecte uneperte car il ya une autre qui émet en même temps, et donc les deux vont régler cwnd d ’unefaçon à ne plus perdre de paquets), un constat validé par la seconde courbe qui permet de direqu’il y un partage de ressources équitable entre chaque connexion TCP, vu l’égalité des débits

instantanés des deux trafics.

Deuxième scénario

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’à l’ouverture

d’une connexion UDP ou on commence à remarquer que le nombre de paquets envoyés parUDP augmente énormement au détriment du flux TCP.

Interprétations :

UDP ne fait pas le contrôle de congestion et donc il se permet d ’envoyer autant qu il veut etdonc le nombre de paquets UDP augmente enormement et UDP ne remarque pas qu’ il y a despaquets perdus.

Par contre TCP qui lui fait le contrôle de congestion detecte qu’il a des paquets perdus, doncil rerduit son debit mais il remarque toujours qu il y a de perte car UDP a saturé la bande etdonc il a toujours son cwnd à 1 et son debit est presque nul

Remarque :

le débit instantané d’envoi des paquets UDP est de 6000*1500*8=72Mbps, qui est beaucoup

plus grand que la capacité réelle du lien physique. On en conclut qu’il y aura certainement uneperte de paquets côté reception.



9

Troisième scénario :

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 réseau, mais le débit de A→B et plus grands que le débit de A’→B ‘

parce que le délai de propagation de A→B est plus petit que le délai de propagation de

A’→B , car on est toujours oblige de recevoir les acquittements avant d’envoyer ce qui tardeA’ à envoyer et donc le débit de la connexion A’→B ‘ est plus petit que celui de A→B.A l’arrêt de la connexion A’→B ‘, la connexion A→B reprend toute la capacité du réseau.

TP Pro Toc Oles de Tra-meziane_Rapport

Documents

Transcript of TP Pro Toc Oles de Tra-meziane_Rapport