INF3270-Chap3-Couche_Transport-Partie_2-2s

INF3270-Chap3-Couche_Transport-Partie_2-2s - Chapitre 3...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Chapitre 3 Couche transport Partie 2 Redouane Zidane UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 3-1 Sommaire 3.1 Services de la couche transport 3.2 Multiplexage et démultiplexage 3.3 Transport en mode non-connecté: UDP 3.4 Principes de transfert fiable de données Matériel basé sur la référence :J.F. Kurose and K.W. Ross, “Computer Networking” 5th Edition, AddisonWesley, 2009 UQAM - Session Autome 2011 3.5 Transport en mode connecté: TCP Structure du segment Transfert fiable des données Contrôle de flux Gestion de la connexion 3.6 Principes du contrôle de congestion 3.7 Contrôle de congestion dans TCP R Zidane - INF3270 - Téléinformatique 3-2 1 Position de TCP dans la pile de protocoles TCP/IP Source: The McGraw-Hill Compagnies UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 3 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 Point-à-point: Données en full duplex: Un émetteur, un récepteur Flot de données bi-directionnel dans la même connexion Transfert fiable, ordonné: MSS: maximum segment size Pipelining: Contrôle de flux et de congestion définissent la taille de la fenêtre d'émission Tampon-mémoire d'émission et de réception mode connecté: Initialisation de la connexion (échange de msgs de contrôle) avant l'échange de données Flux controlé: Émetteur ne peut submerger le récepteur socket door application writes data application reads data TCP send buffer TCP receive buffer socket door segment UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 3-4 2 Structure du segment TCP URG: urgent data (généralement non utilisé) ACK: ACK # valide PSH: envoyer données maintenant (généralement non utilisé) 32 bits source port # dest port # sequence number Compte par octets de données (pas les segments) acknowledgement number head not len used RST, SYN, FIN: Commandes d’établissement de connexion UA PRS F Receive window checksum Urg data pointer Options (longueur variable) Données application (longueur variable) Internet checksum (comme dans UDP) UQAM - Session Autome 2011 Nombre d’octets de données que le récepteur peut accepter R Zidane - INF3270 - Téléinformatique 3-5 TCP: Numéros de séquence et de Segment envoyé de l’émetteur ACKs (1) source port # Numéro de séquence: Numéro du premier octet du segment. de données dans le flux des octets dest port # sequence number acknowledgement number rwnd urg pointer checksum Taille de fénêtre (rwnd) N ACKs: Numéro de séquence du prochain octet attendu Numéro séquence émetteur envoyés ACKés ACK cumulatif Q: Comment le récepteur traite les segments hors séquence source port # R: La spéc de TCP ne dit rien : Dépend de l’implémenteur UQAM - Session Autome 2011 Pas envoyés, Non pas encore encore utilisable envoyés ACKés (“en vol”) R Zidane - INF3270 - Téléinformatique dest port # sequence number acknowledgement number rwnd rwnd checksum urg pointer Segment arrivant à l’émetteur 3-6 3 TCP: Numéros de séquence et de ACKs (2) Hôte B Hôte A Util. tape ‘C’ Hôte ACK la réception de ‘C’, renvoi le car. ‘C’ Hôte ACK la réception du car. ‘C’ temps simple scénario de telnet UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 3-7 TCP: Round Trip Time et Timeout Q: Comment initialiser la valeur timeout de TCP? Plus grande que RTT EchantillonRTT varie l’estimation de RTT Trop petite: timeout prématuré Retransmissions inutiles UQAM - Session Autome 2011 EchantillonRTT: temps mesuré depuis la transmission du segment jusqu’à la réception du ACK Ignore les retransmissions Mais RTT varie Trop grande: réaction lente à la perte d’un segment Q: Comment estimer le RTT? lisser moyenne de plusieurs mesuresrécentes pas seulement le EchantillonRTT courant R Zidane - INF3270 - Téléinformatique 3-8 4 TCP: Round Trip Time et Timeout RTTEstimé = (1- α)* RTTEstimé + α*EchantillonRTT valeur typique: α = 0.125 RTT: gaia.cs.umass.edu to fantasia.eurecom.fr 350 Exemple d’estimation du RTT RTT (milliseconds) 300 250 200 150 100 1 UQAM - Session Autome 2011 8 15 22 29 36 43 50 57 64 71 78 85 R Zidane - INF3270 - Téléinformatique (seconnds) time SampleRTT 92 99 106 3-9 Estimated RTT TCP: Round Trip Time et Timeout Calcul du timeout RTTEstimé plus une “marge de sécurité” grande variation de RTTEstimé 1. grande marge de sécurité Estimer d'abord la déviation de EchantillonRTT par rapport au RTTEstimé: DevRTT = (1-β )*DevRTT + β *| EchantillonRTT - RTTEstimé | (typiquement, β = 0.25) 2. Établir ensuite l’intervalle de timeout IntervalleTimeout = RTTEstimé + 4*DevRTT UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 3-10 5 TCP: Transfert fiable des données (TFD) TCP implémente un service de TFD au dessus du service non fiable de IP « Pipelining » des segments Retransmissions declenchées par : ACKs cumulatifs TCP utilise un seul compteur pour les retransmissions Initiallement, on considère un émétteur TCP simplifié: Événement de timeout ACKs dupliqués ignorer les ACKs dupliqués ignorer le contrôle de flux et le contrôle de congestion UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 3-11 TCP: Évènements de l’émetteur Données reçues de la couche application: Création de segment avec un num. de séq. Num. de séq. = numéro du premier octet de données dans le segment Démarrer le compteur si ce n'est déjà fait Intervalle d’expiration: IntervalleTimeout UQAM - Session Autome 2011 timeout: Retransmettre le segment qui a causé le timeout Redémarrer le compteur ACK reçu: Si acquittement reçu sur des segments non acquittés Prendre note de ce qui reste à acquitter Redémarrer le compteur si des segments restent encore à acquitter R Zidane - INF3270 - Téléinformatique 3-12 6 TCP: Scénarios de retransmission (1) Seq=92 timeout X perte DébutFenêtre = 100 DébutFenêtre = 120 DébutFenêtre = 100 DébutFenêtre = 120 Scénario ACK perdu temps Hôte B Seq=92 timeout timeout Hôte A Hôte B Hôte A temps Scénario timeout prématuré R Zidane - INF3270 - Téléinformatique UQAM - Session Autome 2011 3-13 TCP: Scénarios de retransmission (2) timeout Hôte A Hôte B X perte DébutFenêtre = 120 temps scénario ACK cumulatif UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 3-14 7 TCP: Génération de ACK [RFC 1122, RFC 2581] Évènement au récepteur Action récepteur TCP Arrivée d'1 seg. dans l'ordre avec num. séq. attendu. Ttes données jusqu'au num. séq. ACKées Retarder le ACK: Attendre 500ms l'arrivée du prochain seg. Si pas de prochain seg., envoyer ACK Arrivée d'1 seg. dans l'ordre avec num. séq. attendu. Un autre seg. a le ACK en suspens Envoyer immédiatement un seul ACK cumulatif: ACKer plusieurs segments arrivés dans l'ordre Arrivée d'un seg. hors séq. (plus grand que num. séq. attendu) Écart (gap) détecté Envoyer immédiatement un ACK dupliqué indiquant le num. séq. du prochain octet attendu Arrivée d'un segment remplissant partiellement ou totalement l’écart Envoyer immédiatement un ACK Si le segment commence à la borne inférieure de l’écart UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 3-15 Retransmission rapide (Fast Retransmit) L'intervalle timeout souvent relativement long: long délai avant retransmission du paquet perdu Détecter segments perdus via les ACKs dupliqués. L'expéditeur envoie souvent beaucoup de segments en rafale Si l'émetteur reçoit 3 ACKs pour la même donnée, il suppose que le segment après les données acquittés est perdu: Retransmission rapide: retransmettre le segment avant expiration du compteur (timeout) Si segment perdu, il y aura probablement beaucoup de ACKs dupliqués. UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 3-16 8 Hôte A Hôte B seq # x1 seq # x2 seq # x3 seq # x4 seq # x5 X ACK x1 ACK x1 ACK x1 ACK x1 timeout triple ACKs dupliqués temps R Zidane - INF3270 - Téléinformatique UQAM - Session Autome 2011 3-17 Contrôle de flux TCP Le côté récepteur d'une connexion TCP gère un tampon-mémoire: Fenêtre récepteur (rwnd) Contrôle de flux l'émetteur ne doit pas faire déborder le tamponmémoire du récepteur trop rapidement Processus Paquet IP Espace disponible Données TCP dans application tamponmémoire service correspondance de vitesse (speed-matching) : Tampon-mémoire du récepteur Les processus applications peuvent être lents à lire dans le tampon-mémoire UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique Faire correspondre le taux d'envoi des segments avec le taux d'absorption des données par les applications 3-18 9 Contrôle de flux TCP: Comment ça fonctionne Fenêtre récepteur (rwnd) Processus Paquet IP Espace disponible Données TCP dans application tamponmémoire Tampon-mémoire du récepteur (Supposons que le récepteur rejette les segments arrivés hors séquence) Espace disponible dans le tampon-mémoire Le récepteur indique l'espace disponible en ajoutant la valeur de FenêtreRcpt (rwnd) dans l’entête des segments L'émetteur limite les données non acquittés à FenêtreRcpt = FenêtreRcpt (rwnd) = BufferRcpt-[DernierOctetReçu DernierOctetLu] UQAM - Session Autome 2011 Garantit que le tamponmémoire du récepteur ne déborde pas R Zidane - INF3270 - Téléinformatique 3-19 Gestion de la connexion TCP (1) Rappel: L'émetteur et le récepteur TCP établissent une “connexion” avant d'échanger les segments de données Initialisation des variables TCP: Numéros de séquence Tampon-mémoire, infos de contrôle de flux (ex. FenêtreRcpt) client: Initiateur de la connexion Socket Socketclient = new Socket("hostname",“port"); serveur: contacté par le client Socket Socketconnection = SocketEcoute.accept(); UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 3-20 10 Gestion de la connexion TCP (2) Établissement de connexion (Three way handshake): client serveur Étape1: le poste client envoi au serveur le segment SYN TCP Spécifie le numéro de séquence initial Pas de données Étape2: le poste serveur reçoit SYN, répond avec le segment SYN-ACK Le serveur alloue les tampon-mémoires Le serveur spécifie son numéro de séquence initial Étape3: le client reçoit SYN-ACK, répond avec le segment ACK, qui peut contenir des données UQAM - Session Autome 2011 temps temps R Zidane - INF3270 - Téléinformatique 21 Gestion de la connexion TCP (3) Fermeture de connexion: Le client ferme la socket: Socketclient.close(); client serveur fermer Étape 1: client envoie au fermer serveur le segment de contrôle TCP FIN Étape 2: serveur reçoit FIN, répond avec ACK., ferme la connexion et envoie FIN. temps UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique temps 3-22 11 Gestion de la connexion TCP (4) client Step 3: client reçoit FIN, serveur fermeture répond avec ACK. Entre dans une période d’attente – au cas où le ACK est perdu et un autre FIN est reçu Step 4: serveur, reçoit ACK. Connexion fermée. fermé Temps d’attente fermeture fermé temps UQAM - Session Autome 2011 temps R Zidane - INF3270 - Téléinformatique 3-23 Sommaire 3.1 Services de la couche transport 3.2 Multiplexage et démultiplexage 3.3 Transport en mode non-connecté: UDP 3.4 Principes de transfert fiable de données 3.5 Transport en mode connecté: TCP Structure du segment Transfert fiable des données Contrôle de flux Gestion de la connexion 3.6 Principes du contrôle de congestion 3.7 Contrôle de congestion dans TCP UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 3-24 12 Principes du contrôle de congestion Congestion: Définition informelle: “beaucoup de sources envoyant beaucoup trop de données, trop rapidement pour que le réseau les traite” Différent du contrôle de flux Résultats: Paquets perdus ( débordement des tampon-mémoires des routeurs) Délais importants (mise en file d’attente dans mémoiretampon des routeurs) Top-10 des problèmes de réseau ! UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 3-25 Causes/côuts de la congestion: Scenario 1 Deux émetteurs, deux récepteurs Un routeur, tamponmémoire infini Pas de retransmission Hôte A λin : données originales Hôte B λout Tampon-mémoires partagés de taille infinie Débit maximum réalisable Délai important en cas de congestion (trafic proche de la capacité du lien) UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 3-26 13 Causes/côuts de la congestion: Scenario 2 Un routeur, tampon-mémoire de taille finie Retransmission des paquets perdus λout λin : données originales Hôte A λ'in : données originales + données retransmises Tampon-mémoires partagés de taille finie Hôte B R Zidane - INF3270 - Téléinformatique UQAM - Session Autome 2011 3-27 Causes/côuts de la congestion: Scenario 2 a. Débit optimal quand : λ = λout in b. Retransmission seulement en cas de perte: λ > λout in c. La retransmission d’un paquet retardé (non perdu) donne λout grand pour le même C/2 a. plus λout C/3 λin in C/2 λout C/2 λout C/2 λ C/4 λin C/2 b. C/2 λin c. Coûts de la congestion Plus de travail (retransmissions) pour un débit donné Retransmissions inutiles: le lien transporte des copies multiples des mêmes paquets UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 3-28 14 Approches pour contrôler la congestion Deux approches en général: Contrôle de congestion par les systèmes terminaux : Pas de feedback du réseau La congestion déduite par les observations des systèmes terminaux : perte, délai Approche adoptée par TCP UQAM - Session Autome 2011 Contrôle de congestion assistée par le réseau : Les routeurs fournissent un feedback aux systèmes terminaux Un bit indicant la congestion (SNA, DECbit, TCP/IP ECN, ATM) L'émetteur se doit d’émettre à un certain débit R Zidane - INF3270 - Téléinformatique 3-29 Sommaire 3.1 Services de la couche transport 3.2 Multiplexage et démultiplexage 3.3 Transport en mode non-connecté: UDP 3.4 Principes de transfert fiable de données 3.5 Transport en mode connecté: TCP Structure du segment Transfert fiable des données Contrôle de flux Gestion de la connexion 3.6 Principes du contrôle de congestion 3.7 Contrôle de congestion dans TCP UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 3-30 15 Contrôle de congestion dans TCP (1) But: L’émetteur TCP doit transmettre aussi vite que possible mais sans congestionner le réseau Q: Comment trouver le débit juste en dessous du niveau de congestion Approche décentralisée: Chaque Émetteur TCP établit son propre débit, basé sur le feedback du récepteur: ACK: Un segment reçu réseau non congestionné augmenter le taux d’envoi des segments Segment perdu: Assumer que la perte est due à la congestion du réseau diminuer le taux d’envoi des segments UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 3-31 Contrôle de congestion dans TCP (2) Approche: augmenter de façon continue le débit de Débit d’envoi transmission à la réception de ACKs, jusqu’à la perte d’un paquet, ensuite diminuer le débit de transmission ACKs en cours de réception X Perte Augmenter le débit X X X X diminuer le débit Le comportement en dents de scie de TCP “sawtooth” temps Q: À quel taux augmenter ou diminuer la transmission de paquets? UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 3-32 16 Contrôle de congestion dans TCP (3) L’émetteur contrôle la transmission en limitant le nombre d’octets non acquittés LastByteSent-LastByteAcked ≤ cwnd Les transmissions de l’émetteur sont limitées cwnd par min(cwnd,rwnd) octets Débit= cwnd RTT octets/sec RTT cwnd est dynamique, fonction de la congestion perçue du réseau UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique ACK(s) 3-33 Contrôle de congestion dans TCP (4) Segment perdu: réduire débit timeout: pas de réponse du récepteur Réduire cwnd à 1 3 ACKs dupliqués: au moins quelques segments ont été reçus (rappel de “fast retransmit”) Réduire cwnd de moitié ACK reçu: augmenter débit Phase démarrage lent (slowstart) Augmentation rapide (malgré le nom) au début de la connexion ou après un timeout Évitement de la congestion Augmenter le débit de façon linéaire Moins aggressive que le timeout UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 34 17 TCP: Démarrage lent (Slow Start) cwnd = 1 MSS Exemple: MSS = 500 octets & RTT = 200 msec Débit initial = 20 kbps La bande passante disponible peut être >> MSS/RTT Augmenter exponentiellement le débit jusqu’à la perte d’un segment ou quand le seuil est atteint Hôte A Hôte B RTT Début de la connexion Doubler cwnd à chaque RTT Réception d’un ACK Réalisé en incrémentant cwnd de 1 à chaque ACK reçu R Zidane - INF3270 - Téléinformatique UQAM - Session Autome 2011 temps 3-35 Exemple “Slow Start” 0RTT 1 Un pqt 1RTT 1 2 3 2RTT 2 3 4 5 3RTT 4 6 7 5 8 9 UQAM - Session Autome 2011 6 10 11 7 12 13 14 15 R Zidane - INF3270 - Téléinformatique 36 18 Diagramme d’une séquence “Slow Start” . . . No Sequence Paquets Acks UQAM - Session Autome 2011 Temps R Zidane - INF3270 - Téléinformatique 37 TCP: Évitement de congestion Quand cwnd > ssthresh augmenter cwnd lineairement Agmenter cwnd de 1 MSS par RTT Approche plus lente que dans « slowstart » Implémentation: cwnd = cwnd + MSS/cwnd pour chaque ACK reçu UQAM - Session Autome 2011 AIMD ACKs: augmenter cwnd de 1 MSS par RTT augmentation additive Perte: diviser cwnd par deux à chaque perte diminution multiplicative AIMD: Additive Increase Multiplicative Decrease R Zidane - INF3270 - Téléinformatique 3-38 19 Sommaire: Contrôle de congestion dans TCP Plusieurs saveurs de TCP: Reno, Tahoe, Vegas, SACK, … Quand cwnd < ssthresh émetteur dans phase slowstart fenêtre croît exponentiellement. Quand cwnd >= ssthresh émetteur dans phase évitement de congestion fenêtre croît linéairement. Quand triple ACK dupliqués ssthresh établi à cwnd/2 TCP Reno cwnd établi à ssthresh TCP Tahoe cwnd établi à 1 MSS Quand timeout établi à 1 MSS augmentation linéaire augmentation exponentielle ssthresh établi à cwnd/2 cwnd TCP Reno = TCP Tahoe UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 3-39 Exemple de contrôle de congestion dans TCP – Case d’un time-out Taille de fenêtre cwnd (en segments) ssthresh TCP Reno=TCP Tahoe RTTs Source: The McGraw-Hill Compagnies UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 3-40 20 Taille de fenêtre cwnd (en segments) Exemple de contrôle de congestion dans TCP – Case d’un « Triple Acks dupliqués » TCP Reno ssthresh ssthresh TCP Tahoe RTTs UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 3-41 Débit moyen de TCP (Throughput) Débit moyen TCP = 1.22 ⋅ MSS RTT L L = probabilité d' un paquet perdu Exemple: Segments de 1500 byte, RTT=100ms, Débit désiré = 10 Gbps ➜ L = 2·10-10 pas réaliste UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique augmenter MSS 3-42 21 Exercices TCP Exercice 1 Considérons l'effet de l'utilisation du « SlowStart » sur une ligne avec un RTT de 10 ms sans congestion. La fenêtre du récepteur est de 24 Kb avec un MSS de 2 Kb. Le seuil est au départ fixé à 32 Kb et on suppose que la source désire émettre en continu. Combien de temps ça prend pour que la taille de la fenêtre de congestion soit maximale sans tenir compte des délais d'émission et de réception ? Exercice 2 Supposons que la taille de la fenêtre de congestion de TCP soit égale à 18 Kb (MSS = 1 Kb) et qu'un timeout se déclenche. Quelle sera la taille maximale de la fenêtre de congestion quand 4 transmissions en rafale auront été acquittées normalement ? UQAM - Session Autome 2011 R Zidane - INF3270 - Téléinformatique 3-43 22 ...
View Full Document

Ask a homework question - tutors are online