Vous êtes sur la page 1sur 2

TP TCP Jean-Marie Ferretti

Partie 1 :

Q1 :

a) Pour une taille de fenêtre de 1, l’occupation du buffer reste nul, donc la liaison est très peu
remplie, de plus, on ne voit sur l’animation que de petites salves d’un seul paquet.

b) Les deux premiers segments sont de taille : 40 bytes

Ils servent à l’établissement de la connexion et ne comporte donc aucune donnée

Q2 :

a) On ne constate ici que la fonction d’augmentation du nombre de paquet de l’algorithme slow


start, en effet, la fenêtre n’étant pas assez importante, on n’observe pas de congestion et
donc pas de perte de paquet qui pourrait montrer le mécanisme de gestion de congestion.

b)

Non la liaison n01 → n1 est plus remplie que pour une taille de fenêtre à 1 mais conserve un modèle
d’envoi par « salve » ce qui induit des temps morts dans le fonctionnement de la liaison. On observe
cependant que le buffer de n0 se remplit au début de l’algorithme.

Q3:

Avec les caractéristiques de la liaison, on trouve une taille de fenêtre optimale de 20. Cependant, en
affinant la visualisation, on peut voir que la liaison n’est pas totalement occupée.

La formule étant la suivante : (10Mb / 8)*16ms

Q4 :

a) Avec cette nouvelle taille de fenêtre, la liaison est effectivement bien remplie.
b) La liaison optimale part du principe que chaque salve d’émission commence à la réception du
premier acquittement de la précédente, or dans le cas où la taille de la fenêtre est
parfaitement adaptée à la liaison, la taille des acquittements fait que le premier arrive après
la fin de la fenêtre d’émission.

Q5) : L’occupation du buffer se stabilise à 19, cela est du au fait que les paquets qui remplissent les
liaisons sont au nombre de 21 soit la liaison optimale +1
Partie 2

Q1 : On voit l’algorithme Slow start être utilisé pour la gestion de la fenêtre qui est multiplié par deux
jusqu’à l’occurrence d’une congestion caractérisé par la croissance linéaire qui s’en suit.

Q2 :

a) Comme dans la question précédente, on peut voir l’utilisation du slow start comme
algorithme de congestion.
b) On peut voir que le nombre de paquet envoyé diminué à un certain moment dans la
simulation, cela veut dire qu’un paquet à été perdu et par conséquent l’algorithme envoie la
moitié des paquets à l’itération suivante.
c) On peut voir que l’émetteur diminue son émission après la perte d’un paquet, on peut donc
dire qu’il n’utilise pas sa fenêtre au maximum.

Vous aimerez peut-être aussi