TD : Couche Transport (TCP)

Transcription

1 TD : Couche Transport (TCP) Exercice 1 : L'échange TCP de la figure ci-dessus correspond au transfert d'une page WEB entre un navigateur WEB et un serveur WEB. On fait l'hypothèse que la requête à la page WEB fait 100 octets et que la page WEB retournée fait 1000 octets. Il n y a pas d erreurs de transmission. Pour chaque segment de données, différentes informations apparaissent. D'une part la présence d'un ou plusieurs des différents indicateurs comme SYN, FIN, ACK. Par ailleurs sur la première ligne deux chiffres sont portés. Le premier chiffre correspond au numéro de séquence du premier octet du segment, le deuxième chiffre correspond au numéro du premier octet du prochain segment à envoyer. Le chiffre entre parenthèses correspond au nombre total d'octets transmis dans le segment. Si le segment est porteur d'un acquittement positif, l'indicateur ACK est mentionné et a coté de lui doit figurer la valeur du champ acquittement du segment TCP. Complétez les numéros de séquence et les numéros d'acquittement qui manquent sur la figure (qui apparaissent sous forme de point d'interrogation). Indiquez à quoi correspondent les différents segments numérotés de 1 à 8. Correction : Page 1/4

2 Exercice 2 : Considérons le transfert d'un fichier de taille illimité sur une connexion TCP classique. La taille maximale des données d'un segment (MMS) est 200 octets. La transmission démarre, nous représentons dans la figure 1 le chronogramme obtenu : Page 2/4

3 # Num Seq Num Ack URG ACK PSH RST SYN FIN Taille Données X X X X Complétez dans le tableau ci-dessus les paramètres associés à chaque segment (Numéros de séquence et d'acquittement, flags et Taille des données). Réponse : # Num Seq Num Ack URG ACK PSH RST SYN FIN Taille Données X X X X X X Page 3/4

4 X X X X X X X X X 0 2. Qu'implique la première perte au niveau des acquittements suivants? L acquittement 7 est perdu, mais le récepteur envoie un autre acquittement (seg 10) suite à la réception du segment de données 9. Non. 3. Le déséquencement observé modifie-t-il les émissions de segments de données? 4. Comment est détectée la première perte d'un segment de données et comment est elle réparée? La détection de la perte du segment 14 est dû à la réception de 3 ack identiques (16, 20 et 21) avant expiration du temporisateur RTO. A noter que le segment 13 ne compte pas dans les ACK dupliqués, car le segment 14 n avait pas encore été généré au moment où le segment 13 est arrivé. La stratégie de retransmission suite à 3 ACK dupliqués est de type retransmission selective : l émetteur ne retransmet que le segment indiqué par les dupack (le segment 14). 5. Comment est détectée la seconde perte d'un segment de données et comment est elle réparée? Le temporisateur RTO pour le segment 15 a expiré avant réception d un ACK Ce segment est considéré comme perdu, et TCP considère que cela est dû à un problème grave (i.e.congestion). La source va considérer que tous les segments envoyés après le segment 15 sont «vraisemblablement» perdus aussi. La stratégie de retransmission est alors de type Go-back-n : l émetteur retransmet tous les segments data depuis le segment 15. Page 4/4

5 Remarque : le récepteur ne sait jamais si la source exécute un algo de retransmission de type sélectif ou go-back-n. Ses acquittements concernent donc toujours le premier octet non reçu. Les segments correctement reçus sont gardés dans le tampon de réception. Exercice 3 : Mécanismes de contrôle de congestion TCP 1. Pour TCP, quel phénomène indique une congestion dans le réseau? Comment précisément peut-on constater cette congestion? Réponse : La congestion est indiquée par le non retour d un acquittement avant l expiration du temporisateur de retransmission. Ce retard s explique soit par la perte du paquet soit par un temps de transport trop long Que se passe t-il dans le routeur pour susciter ce phénomène. Réponse : Le retard provient d une surcharge des files d attente donc de la mémoire d un routeur). La perte peut provenir d un débordement des mémoires d un noeud mais aussi d une perte provoquées explicitement par un élément de réseau. On suppose que la mémoire d un routeur se trouve débordée, et que alors les paquets sont jetés. 3. Pour TCP ce phénomène donne suite à l inférence de la congestion. Mais ce phénomène peut se produire même quand il n y a pas de congestion dans le réseau. Dans quels autres cas un tel phénomène peut-il se produire? Réponse : Les pertes de paquets peuvent se produire si une liaison n est pas fiable. Par exemple, si les paquets sont perdus sur une liaison sans-fil., Dans ce cas, ce n est pas une indication de congestion. Une faille transitoire de routage peut aussi être à l origine d une perte, sans qu il existe de congestion dans le réseau. 4. Si ce phénomène n indique pas toujours une congestion, pourquoi est-ce que l IETF base la norme TCP là-dessus? Pourquoi est-ce que l IETF n a pas défini une norme dans laquelle un routeur constate lui-même un état de congestion et envoi un message explicite à l émetteur? Réponse : La philosophie derrière l Internet est une philosophie de repousser l intelligence aux bords du réseau pour permettre d avoir du matériel très simple au coeur du réseau. On préfère alors avoir une signalisation de congestion qui marche de bout en bout, même si elle n est pas complètement fiable. 5. Pour le contrôle de congestion, TCP utilise un seuil qui indique le débit au dessus duquel on risque de rencontrer de la congestion. Ce seuil est exprimé par un paramètre ssthresh, qui indique un nombre d octets. Pour obtenir le débit seuil on divise ssthresh par la période aller retour entre l émetteur et le récepteur (un «RTT» ou «Round Trip Time» en anglais). Le débit peut varier en dessous et au dessus du seuil ssthresh /RTT. L émetteur maintient un paramètre cwnd qui indique le nombre d octets qu il peut envoyer dans le réseau avant de recevoir un acquittement. (Le nom cwnd est un raccourci pour «congestion window» en anglais, qui veut dire «fenêtre de congestion».) Quand cwnd > ssthresh, l émetteur fait particulièrement attention à ne pas provoquer de congestion. Page 5/4

6 Supposons que ssthresh est à 5000 octets, cwnd est à 6000 octets, et la taille d un paquet est de 500 octets. Un émetteur envoi douze paquets de 500 octets dans une période RTT, et reçoit douze acquittements (un pour chaque paquet). Que devient les valeurs de ssthresh et cwnd? Comment s appellent ces changements de valeurs? Réponse : La valeur de cwnd augmente avec la taille d un paquet après avoir reçu les douze acquittements. La nouvelle valeur de cwnd est donc de 6500 octets. Cela s appelle «l accroissement additif» («additive increase» en anglais). La valeur de ssthresh ne change pas. A noter que la valeur de cwnd augmente de la taille d un paquet par RTT, et non par acquittement (qui serait une augmentation beaucoup plus rapide). Dans notre exemple, l émetteur envoie douze paquets dans le premier RTT. Dans le deuxième RTT il va pouvoir envoyer treize paquets. Une précision : les implémentations de TCP ont le droit d augmenter cwnd d une manière approximativement linéaire. Plusieurs implémentations, par exemple, augmente cwnd par MSS*2/ cwnd pour chaque acquittement reçu (où MSS est la taille maximale d un paquet Maximum Segment Size). Ceci peut impliquer une accroissement plus que linéaire ou moins que linéaire dépendant de si on accumule les acquittements. 6. Supposons que ssthresh est toujours à 5000 octets, que cwnd est maintenant à octets, que l émetteur envoi /500 = 28 paquets, et que l émetteur reçoit une indication de congestion avant de recevoir le premier acquittement. Que devient les valeurs de ssthresh et cwnd? Comment s appel ces changements de valeurs? Réponse : La valeur de ssthresh va devenir la moitié de la valeur cwnd, c'est-àdire 7000 octets. La valeur de cwnd devient la taille d un paquet, c'est-à-dire 500 octets. Cela s appelle la «réduction multiplicative» («multiplicative decrease» en anglais). Pourquoi dit-on «multiplicative» quand cwnd retourne toujours à la taille d un paquet? Parce que cwnd va rapidement remonter à la nouvelle valeur de ssthresh, qui est la moitié de l ancienne valeur de cwnd. Une précision : la valeur de ssthresh ne peut pas descendre plus bas que la taille de deux paquets (c'est-à-dire 1000 octets dans notre exemple). Une autre précision : ici on suppose que cwnd octets ont été «perdus» dans le réseau. C'est-à-dire qu il y a cwnd octets non acquittés. La formule précise est de fixer ssthresh à la moitié du nombre d octets non acquittés. 7. Nous venons de voir comment on augmente et comment on diminue cwnd en fonction de l absence ou la présence d indicateurs de congestion. Comment s appelle cet algorithme? Quelle est l idée derrière cet algorithme? Réponse : L algorithme s appelle «l évitement de congestion» («congestion avoidance» en anglais). Il implémente une politique AIMD («Additive Increase, Multiplicative Decrease»). L idée est d augmenter lentement le débit afin de ne pas produire trop de congestion, et de diminuer le débit très rapidement au cas où on a une indication de congestion. Page 6/4

7 8. Au démarrage, et après avoir reçu une indication de congestion, la valeur de cwnd est plus petite que la valeur de ssthresh. Décrivez la manière permettant d augmenter cwnd quand cwnd < ssthresh, en fonction de l exemple suivant. Supposons que ssthresh soit égal à 3000 octets et que cwnd soit égal à 500 octets, la taille d un paquet. L émetteur à plusieurs paquets prêts à être envoyer. Combien de paquets envoie l émetteur pendant la première période RTT? S il reçoit des acquittements pour tous ses paquets, que devient la valeur de cwnd? Combien de paquets envoie l émetteur pendant la deuxième période RTT? S il reçoit des acquittements pour tous ses paquets, que devient la valeur de cwnd? En générale, comment évolue la taille de cwnd? Réponse : Dans la première période RTT l émetteur envoie un paquet de 500 octets. Quand il reçoit l acquittement il augmente cwnd à 1000 octets. Dans la deuxième période RTT l émetteur envoie deux paquets de 500 octets chacun. Ayant reçu les deux acquittements, il augmente cwnd de 1000 octets à 2000 octets. En général, il augmente cwnd par la taille d un paquet (500 octets) pour chaque acquittement reçu. Cela revient à doubler cwnd dans chaque période RTT si l émetteur reçoit un acquittement pour chaque paquet envoyé. Ce processus continue jusqu à ce que cwnd atteint ssthresh. A ce moment, l émetteur bascule vers l «évitement de congestion». Une précision : certaines implémentations de TCP regroupent les acquittements, envoyant un acquittement pour deux paquets reçus. Dans ce cas, l augmentation de cwnd est moins qu exponentiel. 9. Comment s appelle la période pendant laquelle cwnd est plus petit que ssthresh? Réponse : «le démarrage lent» («slow start» en anglais). Le slow start n est pas vraiment «slow» -- il s agit d une augmentation exponentielle du débit de transmission. Mais, on l appelle «slow» parce qu on commence avec un débit faible. 10. Que devient la valeur de ssthresh si l émetteur reçoit une indication de congestion pendant que cwnd est plus petit que ssthresh? Réponse : ssthresh devient toujours la moitié du nombre d octets non acquittés. C'est-à-dire cwnd/2 s il y a cwnd octets non acquittés. Exercice 4 : Illustration du mécanisme de contrôle de congestion TCP Le contrôle de flux de TCP repose sur le principe que la perte d un paquet est due à une congestion dans le réseau. Aussi, lorsqu une perte est détectée, la procédure de contrôle de congestion se met en place. Lors de l envoi des données, le protocole augmente au fur et à mesure la vitesse d émission jusqu à ce qu une perte apparaisse. Alors le protocole ralentit automatiquement son débit afin de palier d éventuelles pertes additionnelles. Ce principe permet d éviter que les retransmissions de données ne viennent s ajouter à la congestion déjà existante. Rappel des algorithmes slow-start et congestion avoidance : A l'initialisation d'une connexion : cwnd := MSS (1 segment) Page 7/4

8 ss-threshold := 64 Koctets (65535 octets) AllowedWindow = min (cwnd, AdvertisedWindow) Lorsqu'une congestion est détectée, à chaque expiration du temporisateur : ss-threshold := fligthsize / 2 cwnd := MSS (1 segment) Lorsque des données sont acquittées, cwnd est augmenté : IF cwnd ss-threshold THEN cwnd := cwnd + MSS (ou cwnd + 1 MSS par ACK reçu) (slow-start) ELSE cwnd := cwnd + MSS2/cwnd (ou cwnd + 1 MSS par RTT, si aucune perte) (congestion avoidance). Tracer un diagramme illustrant l'évolution de la fenêtre de congestion (cwnd) de TCP en fonction du temps, sous les hypothèses suivantes : la taille maximum de segment est de 1024 octets, initialement, la fenêtre de congestion est de 64 Koctets, l'unité de temps utilisée est le délai aller-retour (RTT), au temps 0, la connexion démarre et au temps 14, le temporisateur de retransmission vient d'expirer. Response : Temps Réception ss-threshold Mécanisme cwnd Emission max. 0 Time Out 64Ko/2 = 32Ko Slow Start 1 1 segment 1 1 ACK 32Ko Slow Start 1+1 = 2 2 segments 2 2 ACK 32Ko Slow Start 2+2 = 4 4 segments 3 4 ACK 32Ko Slow Start 4+4 = 8 8 segments 4 8 ACK 32Ko Slow Start 8+8 = segments 5 16 ACK 32Ko Slow Start = segments 6 32 ACK 32Ko Cong. Avoid = segments 7 33 ACK 32Ko Cong. Avoid = segments 8 34 ACK 32Ko Cong. Avoid = segments 9 35 ACK 32Ko Cong. Avoid = segments ACK 32Ko Cong. Avoid = segments ACK 32Ko Cong. Avoid = segments ACK 32Ko Cong. Avoid = segments ACK 32Ko Cong. Avoid = segments 14 Time Out 40Ko/2 = 20Ko Slow Start 1 1 segment 15 1 ACK 20Ko Slow Start 1+1 = 2 2 segments Page 8/4

9 16 2 ACK 20Ko Slow Start 2+2 = 4 4 segments 17 4 ACK 20Ko Slow Start 4+4 = 8 8 segments 18 8 ACK 20Ko Slow Start 8+8 = segments ACK 20Ko Slow Start Min(threshol d,16+16) = segments ACK 20Ko Cong. Avoid = segments ACK 20Ko Cong. Avoid = segments ACK 20Ko Cong. Avoid. 23 segments ACK 20Ko Cong. Avoid. segments seuil seuil temps Page 9/4