Internet – TCP/IP - Corrigé - La Recherche

SIMULATION D'UN RÉSEAU DE COMMUNICATIONTCP/IP AVEC LES OUTILS NS/NAMSéance de Travaux Dirigés proposée par Alain PIROVANOEtude de cas 1 : multiplexage de flux TCP et UDPQ1 Commentez brièvement ce que vous observez.Les numéros de séquence des segments reçus montrent un comportement normalpour TCP : après une croissance lente imposée par le ‘slow start’, la croissancelinéaire révèle un fonctionnement avec une fenêtre ‘flight size’ constante.Q2 Commentez les résultats obtenus. Qu’en déduisez-vous sur le comportement deTCP en présence du flux UDP (et vice-versa) ?Les résultats obtenus montrent que TCP est ‘contenu’ pour laisser place au flux UDP.Effectivement, en présence du flux UDP les deux flux sont multiplexés. De fait lesacquittements TCP sont plus long à revenir et donc la fenêtre glissante de TCP estralentie.Etude de cas 2 : contrôle de congestion de TCP et gestion desretransmissionsQ1 : La capacité des liens vous paraît-elle pleinement utilisée ? Justifiez votreréponse.L'animation visualisée avec Nam montre qu'après les phases de démarrage de TCP,la capacité est pleinement utilisée puisque à chaque instant le canal est utilisé (fluxcontinu).Q2 : Décrivez et expliquez l'allure de la courbe obtenue.L'observation de l’évolution de la taille de la fenêtre de congestion dans le tempspermet de mettre en évidence la phase de Slow Start (croissance exponentielle dansle temps de la taille de la fenêtre de congestion), la phase de Congestion Avoidance(croissance linéaire dans le temps de la taille de la fenêtre de congestion). Cettetrace ne correspond toutefois pas pleinement à celle de la fenêtre effective. On peutremarquer que la version de TCP simulée prend la valeur de la fenêtre de réceptioncomme valeur initiale pour ssthresh (seuil de passage du 'Slow Start' au 'CongestionAvoidance' pour wnd_size=20).Q3 : Après avoir reporté cette courbe sur votre compte-rendu, tracez sur legraphique une courbe représentant la taille de la fenêtre effectivement utilisée parTCP.

- à t=0,7s : détection de perte + retransmission du paquet avecRTO=RTO*2=2 s armé. Ce paquet est immédiatement perdupuisque le lien est toujours « en panne ». (idem à 1,12 s et 1,9 s)- à t= 2 s : le lien est rétabli mais le timer pour le 1 er paquet perdu n’atoujours pas expiré. Ce paquet ne peut donc pas être retransmis.- à t= 3,6 s : RTO expire + ack non reçu = détection de perte +retransmission paquet avec reprise des échanges.Q7 : Relancez une simulation du système en TCP Reno. Comparez les résultatsavec ceux précédemment obtenus en TCP Tahoe et commentez.Conformément à ce qui a été vu en cours, le comportement de TCP Tahoe et TCPReno est identique dans le cas de détections de pertes de segment sur expiration detimer (RTO) : fermeture de la fenêtre de congestion à un segment (cwnd=1) suivid’un redémarrage lent (slow start). Ce cas est mis en évidence par une coupure delien.Q8 : Comparer les résultats obtenus après la simulation des deux scénarios etcommentez. Justifiez les différences avec la question précédente.Par contre, le comportement de TCP Tahoe et TCP Reno est différent dans le cas dedétections de pertes sur acquittements dupliqués (Fast Retransmit) qui révèle uneperte isolée :- TCP Tahoe : fermeture de la fenêtre de congestion à un segment (cwnd=1)suivi d’un redémarrage lent (slow start).- TCP Reno : fermeture de la fenêtre à cwnd/2 suivi d’un évitement decongestion (congestion avoidance). C’est le ‘Fast recovery’Q9 : En quoi TCP New Reno semble être une amélioration en comparaison àReno ? Expliquez.Enfin ce dernier scénario illustre les avantages de TCP New Reno dans le casparticulier où plusieurs segments non nécessairement consécutifs d’une mêmefenêtre sont perdus. On observe que le fast recovery introduit dans TCP Reno nefonctionne que pour le premier segment perdu. Pour les suivants le timer expireavant l’arrivée des ack dupliqués.Afin d’éviter ce problème, TCP New Reno propose un Fast Retransmit amélioré : sile nouvel ack n ’acquitte pas tout ce que l ’on a envoyé (i.e. toute la fenêtre), alors onretransmet immédiatement les autres segments manquants (i.e. on « reste » en FastRetransmit tant que toute la fenêtre considérée n’a pas été acquittée).