La couche transport - Dr Stephan Robert

Exercice 9Eté 2011 2. Couche transport 19Établissement fiable d’une connexion• C’est simple ? Non !• Scénario– Ordre de versement à une banque• Protocole simpliste : – Tous les paquets du client sont– Établissement deretardés et retransmisconnexion en deux temps1. Demande d’établissement2. ConfirmationHôte AHôte BDemandeDemandeConfirmationHôte ADemandeHôte BVersement 1 mioVersement 1 mioConfirmationConfirmation? ? ?DemandeConfirmationVersement 1 mio? ? ?ConfirmationEté 2011 2. Couche transport 2010

Libération de connexion• C’est simple ? Non plus !• Protocole simpliste– Libération en deux temps• J’ai terminé ! Et vous ?• J’ai également terminé !« Problème des deux armées »– Les deux armée bleues doivent se mettre d’accord sur l’heure del’attaque• Armée 1 : « Attaque à l’aube »• Armée 2 : « Confirmé »– Comment l’armée 2 sait-elle que la confirmation a été reçue ?• L’armée 1 pourrait confirmer la réception de la confirmation– Comment l’armée 1 sait-elle que cette confirmation a été reçue ?– …Eté 2011 2. Couche transport 23Libération d’une connexion dans TCP• Les connexions TCP sont bidirectionnelles– Libération séparément dans les deux sens• Un hôte peut demander la libération d’un sens de laconnexion• L’autre hôte peut continuer à transmettre Segments FIN et ACK pour libérer la connexion dans unsensHôte AHôte B• Ne résout pas le problème des deux armées• Solution pratique :– Retransmission du premier FIN– La connexion est libérée par une temporisation,même si le deuxième ACK n’arrive pasFIN Séq=xACK x+1FIN Séq=yACK y+1Eté 2011 2. Couche transport 2412

Automate à nombre d’états finis deTCP• Résume lecomportement de TCPlors de l’établissementet de libération deconnexionsEté 2011 2. Couche transport 25Transmission fiable• Garantie de la délivrance des données, dansl’ordre de l’émission• Doit être réalisée sur une infrastructure nonfiable(service best-effort d’IP)Éléments de la réalisation1. Numéros de séquence– Les octets transmis sont numérotés, non pas lessegments– SYN et FIN ont également des numéros de séquence2. Acquittement3. Retransmission• Estimation de la temporisation de retransmissionEté 2011 2. Couche transport 2613

Acquittements cumulatifs• L’acquittement d’un numéro de séquence confirme la réceptionde tous les octets avant ce numéro de séquence• Avantages– Il n’est pas nécessaire d’acquitter chaque segment séparément• Les implémentations actuelles acquittent chaque deuxième segment,sauf lors d’un délai trop grand– Un acquittement perdu n’implique pasnécessairement une retransmission• Inconvénient principal– Si un segment intermédiaire a été perdu,le récepteur ne peut pas signaler laréception correcte des segments suivants– L’émetteur retransmettra probablementtous les segments à partir du segmentperdu (Méthode Go-back-n)Temporisation deretransmissionRetransmissionRetransmissionsinutilesHôte ASéq=101Séq=1101Séq=2101Séq=3101Séq=101Séq=1101Séq=2101ACK 101ACK 101ACK 101ACK 101ACK 4101Hôte BSéq=4101Eté 2011 2. Couche transport 27Temporisateur de retransmission• L’expiration d’un temporisateur déclenche laretransmission d’un segment• Problème : quelle valeur choisir pour letemporisateur ?– Valeur trop petite : retransmissions inutiles– Valeur trop grande : attente inutile lors d’une perte• La bonne valeur doit dépendre du temps allerretour normal entre l’émission du segment et laréception de l’acquittementHôte A Paramètres importants de TCP– RTT : Round Trip TimeRTT– RTO : Retransmission TimeoutSéq=xSéq=x+1ACK x+1ACK x+2Hôte BEté 2011 2. Couche transport 2814

Analyse du problème• Théorie des files d’attente– Charge rho = Fréquence des arrivées * Temps de services despaquets• La variance du RTT est inversement proportionnelle à rho– Exemple :• Charge rho=75% peut provoquer des variations du RTT d’un facteur16– Le calcul RTO = β ⋅ SRTT avec beta=2 tolère des variations duRTT d’un facteur 2 Applicable pour une charge maximale du réseau de 30 % !• Solution :– Estimation non seulement du RTT mais aussi de savarianceEté 2011 2. Couche transport 31Méthode améliorée de calculer RTOErr = RTT − SRTTSRTT = SRTT + g ⋅ ErrD = D + h⋅( Err − D)RTO = SRTT + 4D.• Err : différence entre SRTT etnouvelle mesure• D : écart moyen du RTT• g, h : contrôlent la vitesse del’adaptation à desvariations du RTT– Recommandé: g = 1/8, h=1/4Méthode originaleRTORTTmesuréMéthode amélioréeEté 2011 2. Couche transport 3216

Algorithme de Karn• Comment mesurer le RTT si un segment a été retransmis ?– Est-ce que l’ACK concerne le segment original ou laretransmission ?EmetteurRécepteurEmetteurRécepteurRTT mesuréTransmission originaleRetransmissionRTT mesuréTransmission originaleACKRetransmissionACK• Problème de l’ambiguïté de la retransmission• Solution (Algorithme de Karn) : Ignorer les mesures du RTT concernant des segmentsqui ont été retransmisEté 2011 2. Couche transport 33Retransmission rapide• Problème desacquittements cumulatifs– Un segment intermédiairea été perdu– Comment signaler que lessegments suivants sontarrivés ?• Solution :– Lors de la réception d’unsegment en désordre, lerécepteur répète le dernierACK (‘dup ACK’)– Si l’émetteur reçoit 3 dup-ACKs, il retransmet lesegment sans attendre untimeoutHôte AAcquittements dupliqués{RetransmissionSuite de la transmissionSéq=101Séq=1101Séq=2101Séq=3101Séq=101Séq=4101Hôte BACK 101ACK 101ACK 101ACK 101ACK 4101Eté 2011 2. Couche transport 3417

Résumé: service de TCP• Connexions bidirectionnelles• Établissement de connexion– Three-way handshake• Libération de connexion– Séparément pour chaque sens• Service de transmission fiable– Numéro de séquence pour chaque octet transmis– Acquittements cumulatifs– Retransmission déclenchée par un temporisateur• Estimation adaptative du RTTEté 2011 2. Couche transport 35Exercices 8,15,16,18,19Eté 2011 2. Couche transport 3618

Contrôle de flux et de congestion• Objectif Régulation de la vitesse de transmission• Contrôle de flux– Adaptation à la vitesse du récepteur– Évite qu’un émetteur rapide surcharge un récepteurlent• Contrôle de congestion– Adaptation à la vitesse du réseau– Évite des pertes excessives de paquets à cause d’unesurcharge du réseauEté 2011 2. Couche transport 37Rappel : contrôle de flux• Méthode la plus simple :– « Stop and Go » (Envoyer et attendre)• Algorithme– Le récepteur acquitte chaque segmentséparément– L’émetteur ne peut envoyer unnouveau segment qu’après laréception de l’acquittement dusegment précédent Le récepteur peut ralentir latransmission en retardant lesacquittements Simple mais faible utilisation duréseauRTTHôte AMessage 1ACKMessage 2ACKMessage 3ACKMessage 4Hôte BTemps depropagation dB ralentit latransmissionEté 2011 2. Couche transport 3819

Performances du protocole « Stop andGo »• Taux d’utilisation du réseau U :– Rapport entre le débit effectif obtenu D et la capacité du réseau C• Calcul– L mess : longueur d’un message en bits– L ack : longueur d’un ACK en bitsHôte ARTT = ( LMess+ LACKLMessU = =RTT ⋅ C L) / C + 2dMessL+ LMessACK+ 2dCMessage 1Hôte B• Utilisation est inversement proportionnelle au ACK« produit largeur de bande–délai » (bandwidth delay product)BWD = RTT ⋅CMessage 4Eté 2011 2. Couche transport 39RTTACKMessage 2Message 3ACKTemps depropagation dB ralentit latransmissionExemple numérique• Paramètres:– L mess =1000 bit– L ack : 10 bit– Délai de propagation d = 10ms– Largeur de bande C entre1 kb/s et 1 Mb/s Utilisation inférieure à 5% à C = 1 Mb/s Stop and Go n’est approprié que pour lesréseaux à faible produit largeur de bande –délaiUtilisation U120.00%100.00%80.00%60.00%40.00%20.00%0.00%Largeur de bande C (bits/s)Eté 2011 2. Couche transport 4020

Protocole de la fenêtre glissante• Méthode de contrôle de flux plus élaborée• Améliore le taux d’utilisation– Permettant à l’émetteur d’envoyer plusieurs paquets avant de devoirattendre un accusé de réception• Principe– Les données dans la fenêtre peuvent être envoyées sans attendred’acquittement– La réception d’un acquittement permet de glisser la fenêtre à droiteFenêtre glissante... 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ...Réception del’ACK pour 8 et 9Émis et acquittéÉmis nonacquittéPeut être envoyéimmédiatementFenêtre glissanteA envoyer quandla fenêtre glisse... 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ...Émis et acquittéPeut être envoyéimmédiatementEté 2011 2. Couche transport 41Gestion de la fenêtre glissanteHôte AHôte B0 1 2 34 5 6 7 8 9 10...0 1 2 34 5 6 7 8 9 10...Séq 0,1,20 1 2 3 4 5 6 7 8 9 10 ...ACK 3Séq 3,4,5Séq 6,7,8,90 1 2 3 4 5 6 7 8 9 10 ...ACK 6... 4 5 6 7 8 9 10 11 12 13 ...Eté 2011 2. Couche transport 4221

Performances du protocole dela fenêtre glissante• Une fenêtre suffisamment grande permetd’exploiter le canal de transmission à 100 %Hôte A• Taille optimale de la fenêtre :RTT = ( LMess+ LACKWU = 1 =RTT ⋅CW = RTT ⋅C) / C + 2dHôte B La taille optimale de la fenêtre glissante est égaleau produit largeur de bande – délai du canalRTTSeq 1Seq 2Seq 3Seq 4Seq 5Seq 6ACKACKACKACKTemps depropagation dEté 2011 2. Couche transport 43Contrôle de flux dans TCP• Basé sur un protocole à fenêtre glissantemais avec une taille de fenêtre variable• La fenêtre utilisable correspond à la place libredans le tampon du récepteur• Chaque accusé de réception indique en plus lataille de la fenêtre (window advertisement) En variant la taille de la fenêtre, le récepteurpeut contrôler la vitesse de transmission del’émetteurEté 2011 2. Couche transport 4422

Exemple du contrôle de flux dansTCPFenêtre glissante...0 4096 6144...0 2048 4096 6144...Hôte ASéq=0, Long. 2048 octetsACK 2048, Fenêtre 2048Hôte BTampon de réception0 40960 2048 40960 2048 4096 6144Fenêtre fermée...0 2048 4096 6144Séq=2048, Long. 2048 octetsACK 4096, Fenêtre 0ACK 4096, Fenêtre 20480 Tampon plein 4096L'application lit 2048 octets0 2048 4096...0 2048 4096 6144...0 2048 4096 6144Séq=4096, Long. 1024 octets0 3072 4096Eté 2011 2. Couche transport 45Fenêtre fermée• Si le tampon de réception est plein, lerécepteur arrête la transmission en indiquantune fenêtre nulle• Quand la fenêtre est nulle, l’émetteur ne peuttransmettre des données que dans deux cas– Données urgentes (avec le drapeau URG)Hôte A– Sondes de fenêtre (window probes)Fenêtre fermée• Lors d’une fenêtre nulle, la perte de...l’annonce d’une fenêtre non nullecauserait un interblocageAttend l'annoncede fenêtre L’émetteur envoie périodiquementde petits segments d’un octet quiobligent le récepteur de ré-annoncerla fenêtre......ACK x, Fenêtre 0ACK x, Fenêtre 2048Séq=x, Long. 1(Window probe)ACK x+1, Fenêtre 2048Hôte BAttend la réceptionde données...Eté 2011 2. Couche transport 4623

Le syndrome de la « fenêtrestupide »• Silly Window Syndrome– Problème de performances lorsque l’application réceptrice litles données octet par octet Chaque accusé de réception annonce un petit espacedisponible et chaque segment ne transporte qu’une petitequantité de données.ÉmetteurDonnées à transmettre............Fenêtre ferméeACK x, Fenêtre 0ACK x, Fenêtre 1RécepteurTampon pleinL'application lit 1 octetAnnonce fenêtre = 1......Un nouvel octet arriveSéq=x+1, 1 octet...... Tampon plein......Fenêtre ferméeACK x, Fenêtre 0...Eté 2011 2. Couche transport 47Éviter la fenêtre stupide• L’émetteur et le récepteur contribuent à ce problème,donc les deux côtés doivent contribuer à le résoudre• Côté récepteur : ne pas annoncer de petites fenêtres– Ne pas annoncer de nouvelle taille de fenêtre jusqu’à ceque puisse être agrandie• soit par un segment de pleine taille (c'est-à-dire le MSS),• soit par la moitié de l'espace du tampon du récepteur• Côté émetteur : ne pas transmettre de petits segments– Ne pas transmettre un segment que si• un segment de pleine taille peut être envoyé, ou• un segment peut être envoyé qui a au moins la moitié de lataille du tampon de réception• L’ACK du segment précédent a déjà été reçu et toutes lesdonnées du tampon d’émission peuvent être envoyéesEté 2011 2. Couche transport 4824

Exercices 25, 27, 28Eté 2011 2. Couche transport 49Contrôle de congestion• État de congestion– Le réseau n’est plus en mesure de transporter tout letrafic injecté et supprime des paquets• Danger de l’amplification d’une congestion par TCP– TCP réagit à une perte avec une retransmission ce quipeut augmenter la charge du réseau Le contrôle de congestion de TCP doit optimiser ledébit de transmission sans mettre en danger lastabilité du réseau• Défis1. Déterminer la capacité disponible sur le réseau2. Ajuster le débit pour obtenir le débit optimal qui permetun régime de transmission stable et en équilibreEté 2011 2. Couche transport 5025

Comportement stationnaire de TCP• Débit optimal : équilibre stable de la transmission– Taille de la fenêtre = Produit largeur de bande – délai– Un nouveau paquet n’est injecté dans le réseau que si un autreest sorti– Toute une fenêtre de données est en transit entre l’émetteur et lerécepteur– La vitesse de transmission est autorégulée par le débit allerretourÉmetteur Canal RécepteurFenêtre glissante.. 6 7 8 9 10 11 12 13 14 15 ..14 13 12 117Données8910106ACKFenêtre glissante.. 7 8 9 10 11 12 13 14 15 16 ..Données15 14 13 128 9 10 11ACK11Eté 2011 2. Couche transport 51Bases du contrôle de congestion deTCP• La fenêtre de congestion (cwnd, congestion window)– Gérée par l’émetteur pour limiter le débit d’émission– TCP adapte la taille de cwnd au niveau de congestion détecté• Combinaison du contrôle de flux et de congestionFenêtre effective =min( Annonce de fenêtre, cwnd)• Principe du contrôle de congestion– Pour détecter le débit optimal, TCP commence avec une petitefenêtre de congestion et augmente rapidement le débit ( Démarrage lent)– Dès que TCP s’approche à la zone de congestion, TCP augmentle débit plus lentement ( Évitement de congestion)– Dès qu’une perte est détecté TCP ralentit rapidement etaugmente à nouveau lentementEté 2011 2. Couche transport 5226

Démarrage lent (Slow Start)• Motivation– TCP doit fonctionner correctement pour n’importequelle capacité du réseau (entre bits/s et Gb/s)– Il faut éviter de surcharger un lien lent dès le début Petite fenêtre cwnd au début– Il faut rapidement arriver à exploiter la capacité deliens importants Augmentation rapide de cwndAlgorithme Slow Start– Initialement cwnd = 1 MSS– Ensuite cwnd est incrémenté de 1 MSS par acquittement reçu Cwnd double chaque RTTEté 2011 2. Couche transport 53Exemple de Slow StartFenêtre de congestionEmetteurRécepteur1 MSS2 MSSRTTACKRTT4 MSSRTT8 MSSEté 2011 2. Couche transport 5427

Évitement de congestion(Congestion Avoidance)• Dans Slow Start, la taille de cwnd augmente de manière exponentielle• Augmentation doit ralentir quand TCP s’approche au débit optimal• Un seuil d’évitement de congestion indique quand on s’approche à unecongestion– Paramètre ssthresh de TCPAlgorithme Congestion Avoidance– Dès que cwnd > ssthresh, cwnd est agrandie linéairement– Pour chaque acquittement reçu :MSS ⋅ MSScwnd ← cwnd +cwnd Augmentation d’un MSS par RTTEté 2011 2. Couche transport 55ExempleSlow Start et Congestion Avoidance• Au-dessous de ssthresh:Slow Start– Cwnd double chaqueRTT• Au-dessus de ssthresh:Congestion Avoidance– Cwnd croît d’unsegment chaque RTTFenêtre de congestion cwnd524844403632282420161284SlowstartÉvitement decongestionssthresh1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16Temps (multiples de RTT)Eté 2011 2. Couche transport 5628

Variation du seuild’évitement de congestionComment déterminer la valeur du seuil de congestion ssthresh ?– Ssthresh doit représenter la taille ‘optimale’ de la fenêtre decongestion• Lorsqu’il n’y a pas de congestion, ssthresh croît linéairementavec cwnd accroissement additif• Les signal que le débit optimal a été dépassé est la perte d’unpaquet– Théorie des files d’attente• Lors d’une congestion, la longueur des files d’attente peut croître demanière exponentielle• Pour garantir la stabilité du réseau, le débit doit diminuer de manièreexponentielle• Lorsqu’une perte a été détectée, ssthresh est diminué à lamoitié décroissance multiplicative• TCP recommence avec Slow Start (après un timeout)– Pour éviter des rafales de retransmissionsEté 2011 2. Couche transport 57Comportement de cwnd et ssthresh• Trois phases– Slow Start avec unecroissance exponentiellede cwnd– Congestion avoidance(accroissement additifde ssthresh)– Diminution de ssthreshlors d’une perte(décroissancemultiplicative dessthresh)Fenêtre de congestion cwnd524844403632282420161284ssthreshTimeout etretransmissionssthresh1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21Temps (multiples de RTT)Eté 2011 2. Couche transport 5829

Recouvrement rapide (FastRecovery)• L’utilisation de Slow Start après des pertes isolées n’estpas efficace– Si des segments intermédiaires ont été perdus mais lessegments suivants sont arrivés, cela indique unecongestion légère et ne justifie pas Slow Start• Recouvrement rapide pour résoudre rapidement la pertede segments isolés– Utilisé en combinaison avec Retransmission RapideAlgorithme Recouvrement Rapide– Retransmettre rapidement le segment manquant– Diminuer la fenêtre à la moitié– Continuer avec Congestion AvoidanceEté 2011 2. Couche transport 59Exemple de Recouvrement Rapidecwnd=1Hôte ASeg 0Hôte BDémarragelentRecouvrementrapideÉvitement decongestioncwnd=2cwnd=3cwnd=4cwnd=5cwnd=6Dup ACK 1Dup ACK 2ssthresh=3, cwnd=3+3=6 Dup ACK 3cwnd=7 Dup ACK 4cwnd=8 Dup ACK 5cwnd=3ACK 1ACK 2ACK 3ACK 4ACK 5ACK 5ACK 5ACK 5ACK 5ACK 5ACK 11Seg 1Seg 2Seg 3Seg 4Seg 5Seg 6Seg 7Seg 8Seg 9Seg 10Seg 5Seg 11Seg 12Eté 2011 2. Couche transport 6030

Effet de recouvrement rapide sur ledébitcwndcwnda) sans recouvrement rapidetb) avec recouvrement rapidetEté 2011 2. Couche transport 61Résumé du contrôle de congestiondans TCP• La taille de la fenêtre de congestion est variée en fonction dela congestion du réseau– Une congestion est détectée à cause de pertes de paquets• Slow Start : croissance exponentielle du débit– Au début de la connexion et après un timeout de retransmission( congestion sévère)– Permet d’augmenter rapidement le débit• Congestion avoidance: croissance linéaire du débit– Dès que le débit s’approche à la capacité disponible• Seuil d’évitement de congestion ssthresh– Indique la zone critique où une congestion est possible– Accroissement additif et décroissance multiplicative de ssthresh– Ssthresh oscille entre le débit maximum et la moitié de ce débitEté 2011 2. Couche transport 6231

Exercices 31, 33, 34, 35, 36, 37, 38Eté 2011 2. Couche transport 63Gestion active des files d’attente• Le contrôle de congestion de TCP est effectuépar les systèmes terminaux– Les routeurs ne doivent pas être modifiés pour cetteméthode– TCP réagit tard, quand la congestion s’est produite Niveau élevé de la longueur des files d’attente• Meilleure solution– Le réseau avertit TCP d’une congestion avant qu’ellene se produise Méthodes de gestion active des files d’attenteEté 2011 2. Couche transport 6432

Random Early Detection (RED)• Implémenté sur des routeurs• Principe– Le routeur mesure la longueur moyenne de la filed’attente– Dès qu’une congestion s’annonce, le routeur avertitTCP en supprimant de manière aléatoire des paquets– La probabilité d’élimination est une fonction de lalongueur de la file d’attenteEté 2011 2. Couche transport 65Fonctionnement de RED• L avg : longueur moyenne de la file d’attente• S min : Si L avg > S min , RED commence à supprimer des paquets auhasard• S max : Si L avg > S max , RED supprime tous les paquets entrantP(élimination)Seuil maximum S maxSeuil minimum S min1P maxLongueur moyenne L avgS minS maxL avga) Seuils de la longueur de la file d’attenteb) Probabilité d’élimination d’un paquet enfonction de l’occupation moyenne de la filed’attenteEté 2011 2. Couche transport 6633

Comportement de RED• RED permet de réduire la longueur moyennedes files d’attente en offrant le mêmethroughput– Réduction des délais de transfert• Problèmes– Choix des paramètresS min, , S max, P max– Oscillation de lalongueur d’une filed’attenteEté 2011 2. Couche transport 67Comportement de flux dans unréseau• Plusieurs connexions TCP– Problème principal : équité• Chaque connexion doit recevoir une partie équitable de la capacitédu réseau– Difficile à obtenir (et à définir !)• Le comportement d’une connexion TCP dépend– De la capacité des liens traversés– Du délai aller retour du chemin• Exemple1 Mb/s10 ms1 Mb/s100 msR1Connexion 1500 Kb/s10 msConnexion 21 Mb/s10 msR21 Mb/s10 msEté 2011 2. Couche transport 6834

Résultats de simulation• La connexion ‘rapide’ a une CWNDplus grande pendant la plupart dutemps– Connexion 1 réagit plus rapidementaux pertes et agrandit la fenêtreplus rapidement• La connexion rapide obtient 2,5 foisle débit de la connexion lente– Un RTT plus petit signifie que avecmême fenêtre, plus de données sonttransmis par unité de temps00 5 10 15 20 25 30 35 40 45Eté 2011 2. Couche transport 69cwnd (MSS)Segments transmis3025201510500 5 10 15 20 25 30 35 40 452500200015001000500Connexion 1Connexion 2Temps (s)Temps (s)Connexion 1Connexion 2Flux TCP et UDP• TCP adapte le débit aux conditions dans le réseau– Flux élastiques– Approprié pour le transfert de données• UDP transmet avec le débit imposé par l’application– Flux non-élastiques– Adapté aux flux multimédia, qui nécessitent souvent un débitfixe• Exemple : voix sur IP : 64 kb/s500000 Le trafic TCP doit être400000protégé contre le trafic UDP300000– Contrôle d’accès pour letrafic UDP200000– Applications adaptatives qui 100000simulent le comportement de TCPEté 2011 2. Couche transport 70Débit (bits/s)00 2 4 6 8 10 12 14 16 18 20 22 24 26 28Temps (s)Connexion TCPConnexion UDP35

Exercice 42Eté 2011 2. Couche transport 7136