TD : Couche Transport (TCP)

L2 Info&SPI
TD – Systèmes et Réseaux
Institut Galilée
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
L2 Info&SPI
TD – Systèmes et Réseaux
Institut Galilée
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
L2 Info&SPI
#
1
2
3
4
Num
Seq
3999
122
4000
4000
TD – Systèmes et Réseaux
Num
Ack
4000
123
123
URG
ACK
PSH
RST
Institut Galilée
SYN
FIN
X
X
X
X
Taille
Données
0
0
0
200
1. 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 :
#
1
2
3
4
5
6
7
8
Num
Seq
3999
122
4000
4000
4200
123
123
4400
Num
Ack
4000
123
123
123
4200
4400
123
URG
ACK
X
X
X
X
PSH
RST
SYN
X
X
FIN
Taille
Données
0
0
0
200
200
0
0
200
Page 3/4
L2 Info&SPI
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
4600
123
4800
123
123
5000
5200
123
5400
5600
5800
123
123
5000
123
5200
123
5400
123
TD – Systèmes et Réseaux
123
4400
123
4800
5000
123
123
5000
123
123
123
5000
5000
123
5400
123
5400
123
6000
Institut Galilée
X
X
X
X
X
X
X
X
X
200
0
200
0
0
200
200
0
200
200
200
0
0
200
0
200
0
200
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.
3. Le déséquencement observé modifie-t-il les émissions de segments de données ?
Non.
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 5400. 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
L2 Info&SPI
TD – Systèmes et Réseaux
Institut Galilée
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...
2. 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
L2 Info&SPI
TD – Systèmes et Réseaux
Institut Galilée
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 à
14.000 octets, que l’émetteur envoi 14.000/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
L2 Info&SPI
TD – Systèmes et Réseaux
Institut Galilée
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
L2 Info&SPI
TD – Systèmes et Réseaux
Institut Galilée
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 = 16
16 segments
5
16 ACK
32Ko
Slow Start
16+16 = 32
32 segments
6
32 ACK
32Ko
Cong. Avoid. 32+1 = 33
33 segments
7
33 ACK
32Ko
Cong. Avoid. 33+1 = 34
34 segments
8
34 ACK
32Ko
Cong. Avoid. 34+1 = 35
35 segments
9
35 ACK
32Ko
Cong. Avoid. 35+1 = 36
36 segments
10
36 ACK
32Ko
Cong. Avoid. 36+1 = 37
37 segments
11
37 ACK
32Ko
Cong. Avoid. 37+1 = 38
38 segments
12
38 ACK
32Ko
Cong. Avoid. 38+1 = 39
39 segments
13
39 ACK
32Ko
Cong. Avoid. 39+1 = 40
40 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
L2 Info&SPI
TD – Systèmes et Réseaux
Institut Galilée
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 = 16
16 segments
19
16 ACK
20Ko
Slow Start
Min(threshol 20 segments
d,16+16) =
20
20
20 ACK
20Ko
Cong. Avoid. 20+1 = 21
21 segments
21
21 ACK
20Ko
Cong. Avoid. 21+1 = 22
22 segments
22
22 ACK
20Ko
Cong. Avoid.
23 segments
23
23 ACK
20Ko
Cong. Avoid.
segments
…
…
…
…
…
…
40
36
32
seuil
28
24
seuil
20
16
12
8
4
0
2
4
6
8
10
12
14
16
18
20
22
temps
Page 9/4