Upload
mezianew
View
120
Download
0
Embed Size (px)
Citation preview
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
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 2/9
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 :
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 3/9
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
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 4/9
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
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 5/9
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.
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 6/9
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.
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 7/9
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
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 8/9
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.
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 9/9
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.