Service Best-Effort. Plan. Pascal Anelli IREMIA. mardi 14 mars

Transcription

1 Service Best-Effort Pascal Anelli IREMIA 2 Plan Rappel: Contrôle de congestion de TCP Performance de TCP TCP Friendly Modelisation de TCP Evolutions du contrôle de congestion 3 mardi 14 mars

2 Contrôle de congestion de TCP Huston, G. (2000). Cisco Internet Protocol Journal, Vol. 3, No. 2. TCP Performance. 91 Rappel: TCP (Transmission Control Protocol) Protocole de transport avec 2 objectifs: Fiabiliser les échanges - Rendre le service Best-Effort transparent Contrôler le débit de la source de trafic pour réduire les sur-charges du récepteur RFC 793 Initialement Pas de prise en compte du réseau 93 mardi 14 mars

3 TCP initial Pas de prise en compte de l'interaction avec le réseau 1-pre-vj.nam 97 Contrôle de congestion Dans les années 80, l'internet souffre du "Congestion Collapse" Reporté par [Nagle 85] Ignorance sur la dynamique de l'acheminement des paquets dans le réseau La performance dépend de la charge [Chiu 89] Congestion avoidance control Après le knee Délai augmente rapidement Débit augmente lentement Après le cliff Délai tend vers l'infini Débit chute vers zéro Rappel: dans une file M/M/1 Congestion collapse Delay 1 1 ρ Chiu, D.M. et Jain, R. (1989). Computer Networks and ISDN Systems, Vol. 17, pp Analysis of the Increase and Decrease Algorithms for Congestion Avoidance in Computer Networks. 98 mardi 14 mars

4 Congestion collapse Effondrement des performances Dans le cas d'un réseau maillé temps de transfert trafic écoulé capacité max. (c) (a) (b) trafic offert trafic offert Explication Quand un paquet est perdu, les ressources amonts utilisées par ce paquet ont été gaspillées! Modèle du congestion collapse Réponse Les sources doivent ajuster leur débit en fonction de l'état du réseau 100 Contrôle de congestion Motivations Maximiser le taux d'utilisation des ressources Éviter l'effondrement du trafic écoulé (congestion collapse) - Ne pas saturer les tampons mémoires Partager équitablement les ressources: équité (fairness) Fonctionne en boucle fermée Source de trafic élastique Notification de l'émetteur (feedback) Réaction: Ajustement en fonction de la notification Objectif: Maintenir un fonctionnement du réseau en dessous du point de retournement (cliff) 103 mardi 14 mars

5 Choix de mise en oeuvre Destinataire de la notification Contrôle au niveau source (end to end) Contrôle au niveau réseau (hop by hop) Back-pressure Nature de la notification Notification binaire ou information plus riche Implicite - Déduction de l'etat du réseau par observations ou mesures Explicite - Participation du réseau 104 Contrôle de congestion TCP Principes [Jacobson 88] Application de la prévention de la congestion dans un protocole réel Le contrôle opére dans les hôtes (end to end) - Deviner l'état du réseau par la source Rend les flots TCP réactif à un signal de congestion: notification binaire - "dégager le flot" pendant la période de congestion Applique une certaine équité entre les flots Contraintes de mise en œuvre Chaque source détermine elle même la capacité du réseau - Et s'adapte aux variations Contrôle en boucle fermée: notification implicite Jacobson, V. (1988). SIGCOMM'88, Ed. ACM, pp , August. Congestion Avoidance and Control. 105 mardi 14 mars

6 en MSS Contrôle de congestion TCP Conservation des paquets Ne pas injecter un nouveau paquet tant qu un vieux n est pas sorti du réseau ("pipe") - nombre de paquets en transit constant Synchronisation sur les acquittements: auto-synchronisation (self clocking) - les ACKs régulent («clock») l émission des données Idée du contrôle de congestion TCP Trouver un point d'équilibre Emettre au rythme d'équilibre Jacobson, V. (1988). SIGCOMM'88, Ed. ACM, pp , August. Congestion Avoidance and Control. 2-ack_clock.nam 107 Slow-Start Problème du démarrage (ou redémarrage) La transmission des données commence sans aucune connaissance de l état du réseau Pas d'auto-synchronisation Objectifs du Slow Start Eviter d'envoyer une rafale après une période d'inactivité Atteindre rapidement le point d'équilibre ("knee" ) sans rafale Acquisition rapide de l'auto-synchronisation Détection rapide d'une sur-estimation du point d'équilibre Fonctionnement A t= 0, cwnd =1 Augmentation exponentielle: cwnd augmente de 1 MSS par ACK (double la cwnd par RTT) Arrêt de cette croissance qd cwnd ss_thresh cwnd 8 ss_thresh RTT 112 mardi 14 mars

7 Congestion Avoidance Motivations Le point d'équilibre est considéré atteint Sonder le réseau pour obtenir de la bande passante supplémentaire Augmentation linéaire de la fenêtre ("Additive increase") Fonctionnement quand cwnd > SS_threshold Incrémente cwnd de 1 segment par RTT ou de 1/cwnd par ACK 113 Réaction à la congestion Notification négative - Congestion sur la route vers la destination (du pipe) Implicite - Expiration du temporisateur = Indication d'une perte - perte = débordement de file d'attente Hypothèse: Le "cliff" est proche Diminuer la charge le débit d'émission Diminution multiplicative du ss_thresh (facteur 0.5) - Nouvelle valeur cwnd cible 114 mardi 14 mars

8 Illustration 3-post-vj.nam 116 Long Fat Network II Récupération de la perte Attendre l'expiration du temporisateur Repartir en slow start Problèmes Le "pipe" c'est vidé Retransmissions inutiles pour corriger une perte Délai pour recharger le "pipe" Idée Conserver l'auto-synchronisation - Empécher que le pipe se vide Effectuer la retransmission au "fil de l'eau" Rester en phase de congestion avoidance - Eviter de ré-acquérir la synchronisation après une perte - Le "pipe" ne doit pas se vider Astuce pour inférer une perte Récepteur emet un ACK chaque fois qu'il reçoit un segment Un ACK indique le numéro du dernier segment reçu un ACK dupliqué indique un segment manquant 120 mardi 14 mars

9 Reprise idéale Barakat 121 Fast Retransmit / Fast Recovery A la réception du 3e ACK dupliqué ssthresh = max (FlightSize / 2, 2*MSS) retransmettre le segment perdu cwnd = ssthresh + 3 * MSS - 3 = nombre de segments ayant quitté le réseau et stocké par le récepteur A chaque ACK dupliqué reçu cwnd += MSS Transmettre un segment si la nouvelle valeur de cwnd et rwnd le permet Sortie de la reprise: Réception du premier ACK acquittant de nouvelles données - Ack provoqué par la retransmission du segment perdu (donc reçu 1 RTT après) - Ack de tous les segments envoyés après l émission du segment perdu cwnd = ssthresh 124 mardi 14 mars

10 Contrôle de congestion Evolution de cwnd Synthèse des mécanismes Limite de contenance du 'pipe' En régime stationnaire, cwnd oscille autour de la taille de fenêtre optimale 125 Dynamique de TCP 4.19E+06 Sequence number (bytes) 4.18E E E E E+06 RTT Data ACKs Window Duplicate ACKs Fast retransmission 4.13E Time (s) Balakrishnan 126 mardi 14 mars

11 Unix Versions de TCP BSD 4.2 (1983) 1ére souche TCP/IP largement disponible BSD 4.3 Tahoe (1988), slow start, congestion avoidance, fast retransmit BSD 4.3 Reno (1990), fast recovery Le plus largement utilisé de nos jours BSD 4.3 Vegas (1990), Estimateur de BP cwnd Reno Tahoe RTT 127 En résumé Le contrôle de congestion de TCP c'est pour: La source: Une adaptation à l'état du réseau: ne pas saturer les tampons en cas de congestion - Propriété donnée par le MD - Notion de trafic élastique Un taux de perte de paquets plus faible que pour les trafics non élastiques Une agressivité du débit - Propriété donnée par l'ai Le réseau Eviter d'entrer en état d'instabilité (congestion collapse) Elément indispensable au fonctionnement de l'internet "Best Effort" 131 mardi 14 mars

12 Performance de TCP objectifs Débit: Objectifs de performance - Notion de gooput débit reçu à l'interface TCP (hors duplication de paquets) - Visible sous l'aspect de la latence Equité - Concerne le partage du support 133 mardi 14 mars

13 Mesures de la performance Débit d'émission W = Min(cwnd, rwnd) Débit = Débit de réception Débit écoulé (throughput) W RTT Latence Délai de transfert Débit utile (goodput) Débit écoulé sans les retransmissions Débit = Quantité transférée Latence Taux de perte de paquet (PLR) Nb de paquets perdus/ Nb de paquets envoyés Taux de congestion (LER: Loss Event Ratio) Nb de réduction de la fenêtre/nb de paquets envoyés 134 Intéraction avec le réseau Synchronisation des sources Les sources sont informés en même temps (au RTT pres) de la congestion La charge diminue fortement (sur-réaction) La file d'attente passe de l'etat plein à l'état vide Oscillations Le taux d'utilisation de la BP chute Biais contre les sources sporadiques Pertes consécutives, chute importante du débit Solution Changer la gestion de l'attente Notion d'aqm (Active Queue Management) - Répartir les pertes dans le temps - Ne pas attendre le débordement 135 mardi 14 mars

14 Contraintes sur les tampons mémoire Trop petit des pertes apparaissent pendant la phase de Slow-Start - Due à la sporadicité du SS - Même si le ss_threshold est correct Plusieurs phases de Slow-Start consécutives Sous-estimation de la capacité de la route Solutions Utiliser l'ack-clocked pour estimer la contenance du pipe et mettre le ss_threshold à cette valeur Diminuer la sporadicité - Espacer les segments afin d'avoir un débit équivalent à celui du goulot d'étranglement Taille optimale En congestion avoidance: (B+µT)/2 cwnd (B+µT) Débit de TCP = µ quand cwnd µ.t Utilisation à100% du lien si B µ.t Contenance du "pipe" Barakat 136 Equité TCP Objectif Partage équitable de la bande passante du goulot d'étranglement: - Pour N flots, le partage donne t il 1/N de bande passante? Modélisation du système Notification binaire I y( t) = [ if ( x( t) c) then 0 else 1] i i= 1 Réaction de la source pour converger vers un partage équitable? Chiu, D.M. et Jain, R. (1989). Computer Networks and ISDN Systems, Vol. 17, pp Analysis of the Increase and Decrease Algorithms for Congestion Avoidance in Computer Networks. 137 mardi 14 mars

15 Réactions Adaptation du débit à la notification binaire y(t) = 0 x i (t +1) > x i (t) y(t) = 1 x i (t +1) < x i (t) Algorithme d'adaptation linéaire x i (t +1) = a y (t ) x i (t) + b y (t) Actions possibles a 1 >1, b 1 = 0 a 1 =1, b 1 < 0 MD AD a 0 >1, b 0 = 0 a 0 = 1, b 0 > 0 MI AI Choix : Lequel? 138 Représentation vectorielle Cas à 2 sources 139 mardi 14 mars

16 Increase -Decrease a 0 x +b 0 a 0 x x=(x 1, x 2 ) a 1 x a 1 x +b Vers l'équité Observations La multiplicativité ne change rien à l'inéquité AD augmente l'inéquité AI diminue l'inéquité Conclusion Pour converger vers l'équité, il faut Une augmentation additive (AI) une diminution multiplicative (MD) 141 mardi 14 mars

17 AI MD Convergence vers un partage équitable AI augmente la fenêtre de 1 MD diminue le débit proportionnellement (x 1,x 2 ) Partage équitable perte: diminution de cwnd d'un facteur 2 Débit cumulé augmente Flot 2: x 2 Cas idéal: RTT identique MSS identique Flots réactifs Flot 1: x 1 efficiency line 142 Limitation de TCP quand D*BP augmente High speeds: to reach 10gbps, packet losses occur every 90 minutes! Avg. TCP Utilization 50 flows in both directions Buffer = BW x Delay RTT = 80 ms Simulations Avg. TCP Utilization 50 flows in both directions Buffer = BW x Delay BW = 155 Mb/s Bottleneck Bandwidth (Mb/s) Round Trip Delay (sec) Katabi 143 mardi 14 mars

18 TCP friendly 146 Coexistence avec les autres flots Problèmes d équité Plusieurs connexions pour une même application RTT différents D = W RTT Applications non élastiques: cas du multimédia - 3 flots TCP et un flot UDP CBR en compétition à un goulot d'etranglement Floyd- Fall 147 mardi 14 mars

19 Coexistence avec les autres flots Congestion collapse Solutions Notion de TCP friendly pour les sources Ajouter du contrôle dans le réseau - Dans chaque routeur. - A l entrée du réséau Floyd, S. et Fall, K. (1999). IEEE/ACM Transactions on Networking, Vol. 7, No. 4, pp , August. Promoting the Use of End-to-End Congestion Control in the Internet. 148 TCP Friendly Notion de TCP-friendly Idée que TCP définit LE comportement du contrôle de trafic Flot est TCP-friendly si son débit moyen ne dépasse pas celui de TCP dans les mêmes conditions - N'a pas tout le débit qu'il veut Principe Toutes les applications qui produisent des flots importants ("long lived") doivent émiter le comportement de TCP - Ne concernent pas les flots courts Caractéristiques Le débit d'émission varie selon un algorithme adaptatif Une notification sous la forme d'un taux de perte doit pouvoir etre déterminé - Ce taux de perte est utilisé par l'algorithme adaptatif En moyenne, le débit d'émission est le même que TCP dans les mêmes conditions de pertes Mise en oeuvre Applications multimédia adaptative - RTP/RTCP Contrôle de congestion pour les flux continus - TCP Friendly Rate Control (TFRC) 149 mardi 14 mars

20 Modélisation 150 Modélisation de TCP Source "élastique" TCP contrôle son débit en fonction des conditions de traitement de ses paquets par le réseau Objectifs Identification des facteurs de performance du protocole Définition d'une équité pour les flots non TCP: TCP Friendly Modèle TCP Détermination du débit d'émission TCP en fonction d'une réaction donnée du réseau En régime stationnaire 151 mardi 14 mars

21 Hypothèses Connection TCP de durée infinie Pas de temporisateur (pas de slow start) Pas de limitation de la fenêtre annoncée Evolution périodique de la cwnd Modèle SQRT Débit = Nombre de paquets N.MSS Durée cycle S Ou selon le nb moyen de segments/rtt Débit = 3 4 W.MSS RTT (1) Une taille de fenêtre de paquets est émis par RTT avec la durée d'une periode S: cwnd W 2,W S = W 2.RTT Mathis, M.; Semke, J.; Mahdavi, J. and Ott, T.J. (1997). ACM Computer Communication Review, Vol. 27, No. 3, pp , July The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm. 152 Nombre de paquets par cycle: Modèle SQRT Probabilité de perte: p = 1 N N = W(t)dt = 3 8 W 2 0 S (2) (3) W(p): De (2) et (3) N = 1 P = 3 8 W 2 soit W = 8 3p (4) Débit(p): De (1) et (4) Caractérisation du débit de TCP/taux de perte D( p) = 3 2 MSS RTT p D( p) 1 p 153 mardi 14 mars

22 Evaluation Première approximation du débit TCP Débit Inversement proportionnel à p mauvaise performance sur des liens bruités Inversement proportionnel au RTT mauvaise performance sur les liaisons qui introduisent un RTT important (i.e. Satellite) Proportionnel à la taille du segment (MSS) transfert de masse doit utiliser des grands paquets Limitations Ne fonctionne pas quand P est important Temporisateur à prendre en compte Plusieurs paquets sont perdus dans un même RTT Non applicable aux flots courts 154 Prise en compte: Acquittement retardé: b segments par ACK - Pas 1/b de paquet par RTT Du temporisateur - RTO approximé par 4*RTT Modèle PFTK D( p) RTT 2bp 3 MSS 3bp + RTO.min 1,3 p p 2 8 ( ) Acceptation comme le modèle de TCP Reno Padhye, J.; Firoiu, V.; Towsley, D. and Kurose, J. (1998). SIGCOMM '98, Ed. ACM. Modeling TCP Throughput: A Simple Model and its Empirical Validation. 155 mardi 14 mars

23 Evolutions du contrôle de congestion 158 Approches du CC Window-based congestion control Gestion de la cwnd fonction des pertes Equation-based congestion control Notion de TCP-friendly Delay-based congestion control Inférer l'état du réseau à partir de mesures de délai Les hybrides Combinaisons 160 mardi 14 mars

24 Nouveaux protocoles de transport Distinguer le CC du service TCP Pour des flots avec CC mais sans remise fiable Le CC doit être dans pris en compte dans les protocoles de transport 161 TFRC (TCP Friendly Rate Control) Motivations Stabilité de l'internet - Congestion contrôle de bout en bout pour tous les flots Pour les flux streams, variations du débit émis doit être plus faible que pour TCP - Pour une meilleure qualité perçue - Cas de TCP: Réduction du débit TCP de moitié en cas de perte rfc3448 Définition Une autre forme de contrôle de congestion qui coexiste avec TCP dans un internet best-effort. Le débit émis sur le long terme est similaire à celui de TCP. Les réactions aux notifications sont faibles à la hausse ou à la baisse - Réponse sur le long terme - Peu de réactivité aux congestions transitoires Flot unicast Idée générale Equation Based CC - Détermination du débit émis maximum acceptable fonction du LER Emetteur ajuste son débit en fonction d'une équation de contrôle Equation du débit émis selon TCP - Ne pas être agressif vis à vis de TCP : TCP friendly - Mais pas moins que TCP aussi 162 mardi 14 mars

25 Delay based CC Motivation Anticipation de l'état de congestion avant la perte Comment Observation des signes précurseurs du réseau Le RTT augmente Le débit d'émission n'augmente plus cwnd Sending rate Queue Size B 40 K s p B K g 1100 n i r 900 e d 700 t n 500 u e o 300 S r 100 n i e z i s e u e u Q Time (seconds) Time (seconds) Time (seconds) 170 TCP Vegas Idée Ajuste le débit d'émission en fonction du débit écoulé attendu Contrôle du débit par une fenêtre - Taille de la fenêtre: nombre de paquets dans le réseau Maintenir la taille de la fenêtre à la "bonne" valeur - pas trop: risque de congestion - Pas assez : risque de ne pas utiliser la bp disponible 171 mardi 14 mars

26 Expected rate = Algorithme BaseRTT Le RTT minimum mesuré (souvent sur le premier paquet) Détermination des débits Ajustement cwnd BaseRTT Diff = ExpectedRate - ActualRate if Diff < α augmente cwnd linéairement else if Diff > β diminue cwnd linéairement fi bits émis Actual rate = RTT α et β représente la quantité de données min et max que peut contenir le réseau 172 TCP Vegas Avantages Découverte de la BP disponible sans perte Découple la notification de la perte Fenêtre plus stable que TCP Reno - Meilleure utilisation des ressources TCP est équitable quelque soit le RTT Les tampons mémoires sont moins remplis, délais plus court - Bonne coexistence avec les flux streams Les liens à BP*délai important sont mieux utilisé qu'avec Reno - Pour les liens satellites Inconvénient TCP Vegas est désavantagé par rapport à Reno - Comportement conservatif - Cependant goodput plus important 173 mardi 14 mars

27 En Résumé TCP exécute un contrôle de congestion de bout en bout Equité et débit écoulé sont les objectifs Débit d'émission est régulé par une fenêtre dont la taille est asservie à la notification - Pas de perte: AI - Perte: MD TCP présente un biais contre les flots à RTT longs Equité dépend du RTT La file d'attente de multiplexage des routeurs peut améliorer le fonctionnement de TCP TCP suppose la coopération de tous les flots au CC Les flux non TCP doivent être TCP Friendly Le débit débit émis de TCP Autrement inéquité et risque de congestion collapse L "equation based CC" repose sur la formule PFTK 178 mardi 14 mars