Contrôle de congestion au niveau des routeurs. Pascal Anelli, Pierre Ugo Tournoux Laboratoire d'informatique & Mathématiques

Transcription

1 Contrôle de congestion au niveau des routeurs Pascal Anelli, Pierre Ugo Tournoux Laboratoire d'informatique & Mathématiques Informations! Les ressources liées à ce cours sont disponibles en ligne " > «teaching» > «Master 1 Res UPMC» " Elles seront actualisées le 2/04/14! 4h de TME " La semaine du 7/04/14 au 11/04/14! Indispensable pour le TME : " Une liste d exercice reprenant le cours et les rappels sur TCP. " Faites les exercices et lisez le sujet du TME avant d y assister.! Si possible, venez avec votre machine, au minimum une pour deux étudiants " Avec un environnement Unix / Linux configuré (éventuellement une machine virtuelle)! Nous utiliserons NS-2 " Fonctionne sous linux / Unix (Mac Os) " Comment installer ns-2? " Depuis les sources : download " Depuis les packages disponibles sur vos distributions : sudo apt-get install ns2 " Nous utiliserons également l outil gnuplot : sudo apt-get install gnuplot-nox 2

2 Plan! Introduction " Rappels sur TCP " Routeurs, notification et partage des ressources! Passive Queue Management! Active Queue Management! Notification explicite " ECN " ERN 3 Ressources! Contexte " Multiplexage asynchrone des artères de communications " Traitement des contentions à la transmission par une file d'attente! Ressources d'un réseau de paquet " Capacité de transmission: La bande passante des artères " Capacité de mémorisation avant la transmission: la fille d'attente de multiplexage! Comment sont partagées ces ressources entre les différentes flots? 4

3 Contexte de l'internet! Principe du bout en bout a.k.a. End to End (E2E) " Dans l internet, l allocation des ressources se fait par les hôtes eux même. C est eux qui choisissent de s autoréguler. " Les états relatifs aux flots et à la gestion de la capacité qu ils occupent sont donc dans les hôtes " Les différents flots et hôtes ne se synchronisent pas explicitement entre eux. " L allocation des ressources est donc décentralisée. " Cette répartition des ressources s appelle le contrôle de congestion " Détermination du débit d'émission! Contrôle de congestion (CC) " Une notification du réseau (feedback) " Une réponse de la source en terme de débit d'émission " Crédit-based congestion control 5 Objectifs du CC! 2 critères de performance " Débit: " Notion de goodput : débit utile i.e. débit reçu par l application depuis la socket TCP qui reçoit les données. N inclus pas les paquets dupliqués, les entêtes ( ). " Equité : " concerne le partage du support " Métrique : Index de Jain avec x i le débit obtenu par le flot i J(x 1, x 2,..., x n ) =! Maintenir un fonctionnement " Dans la région proche du maximum qui peut être écoulé " Phase de Congestion avoidance! Empêcher le congestion collapse " La congestion est en train de se produire " Phase du Congestion recovery * Si congestion collapse, augmentation du délai et réduction du goodput à cause des pertes et des paquets dupliqués n ( x i ) 2 i=1 n n x i 2 i=1 6

4 Stabilisation du canal! 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 BP Temps goulot Pb Pr Emetteur As Ar Récepteur Ab # Contrôle isarithmique, correspond à la première version de TCP. Jacobson, V. (1988). SIGCOMM'88, Ed. ACM, pp , August. Congestion Avoidance and Control.! 7 Difficultés du contrôle isarithmique! Pas d'auto-synchronisation au démarrage " Aucune information donnée par le réseau! Des inconnues " Capacité d'écoulement " L'état du réseau # La connexion démarre en ignorant tout du réseau! En environnement variant dans le temps " RTT " Ressources disponibles # Le contrôle isarithmique doit s'adapter 8

5 Mise en œuvre de l adaptation du débit! Éviter le congestion collapse " Fenêtre (cwnd) dynamique " Contrôle de la quantité de données en circulation " Variation en fonction de la notification! Outils " Fenêtre de contrôle de congestion: cwnd " Représente la capacité disponible (la contenance du canal a.k.a. pipe) " Sondage de la BP disponible: " Au démarrage: Slow Start, progression exponentielle (*2 par RTT) " En cours: congestion avoidance, progression linéaire (+1 par RTT) " Estimation du knee (point d'équilibre): ss_threshold (valeur à laquelle la source sort du slow start et passe en congestion avoidance) " Reprise rapide en cas de perte (Fast Retransmit) : " Sur 3 ACK dupliqués " Maintenir le canal en activité suite à une perte " Fast Recovery! Équité " Fonction de contrôle de la fenêtre: AI-MD " Augmentation de la taille de sa fenêtre tant qu'il y a aucune perte : additive increase (AI) " Diminution de la taille de sa fenêtre à chaque événement de pertes: multiplicative decrease (MD) 9 Plan! Introduction " Rappels sur TCP " Routeurs, notification et partage des ressources! Passive Queue Management! Active Queue Management! Notification explicite " ECN " ERN 13

6 Gestion des ressources! La congestion se produit dans les routeurs! Limitations de E2E " Prédiction de l'état du réseau : binaire et sans sa collaboration " Pb de performance et " Pb d équité! Solution " Mettre de l intelligence dans le routeur" Organe de commande Paquets/s Bits/s Démuliplexeur Muliplexeur Matrice de commutation " Réagir quand la congestion est imminente ou lorsqu elle est déjà présente. " Prendre un rôle actif dans le contrôle de congestion en complément de celui de E2E " Signaler la congestion aux hôtes afin qu ils adaptent leur débit " Traiter la congestion sans informer les hôtes! Motivations " Améliorer le fonctionnement du contrôle de congestion de TCP " Maintenir un taux d'utilisation des liens importants " Conserver des délais de transfert faibles " Renforcer le partage équitable E. Lochin! Ne traite pas du congestion collapse " Le but est de rester autour du knee (débit écoulé important mais pas de congestion) ligne entrante Modèle de routeur Port Lieu de Congestion ligne sortante 14 Partage équitable! Equité " Règle de partage qui détermine qui doit avoir sa demande non satisfaite! Equité Max-min " Avoir le maximum de flots satisfaits en privilégiant ceux qui demandent le minimum " Maintenir une bonne efficacité au réseau! Principe " Personne n'obtient plus que sa demande " Satisfaire ceux qui demandent le moins " Allocation dans l'ordre croissant des demandes " Tous ceux qui n'ont pas leur demande satisfaite ont une allocation égale Partage égalitaire de l'excédent Demande non satisfaite A B C B C C! Allocation Max-min "Personne ne peut avoir plus au prix d'une diminution de quelqu'un qui a déjà moins" Keshav 15

7 Les traitements dans les routeurs! Au niveau des paquets " Ordre de transmission a.k.a. ordonnancement (Scheduling) " Mise en file d'attente a.k.a. discipline d attente (Queue Management) Gevros, P.; Crowcroft, J.; Kirstein, P.et al. (2001). IEEE Network, Vol. 15, No. 3, May." Congestion Control Mechanisms and the Best Effort Service Model.!! Classiquement, les routeurs de l'internet: " Une file d'attente par interface de sortie " Ordonnancement: FIFO " Discipline d'attente: Pertes à la mise en file (Drop Tail) 17 Discipline d'attente! Objectif " Traiter la perte e.g. déterminer quel paquet doit être perdu! Principe " Gère la file d'attente en fonction d'un niveau de congestion " Produit un feedback à la source " Agit au niveau du paquet " Lequel retenir? " Quand agir? " Service reste FIFO! 2 options " Passive (Passive Queue Management) " Action en phase de congestion recovery " Pas d'anticipation de la congestion " 2 états: Sans perte: pas de congestion Débordement (pertes de paquets): congestion " Active (Active Queue Management) " Action en phase de congestion avoidance " pour prévenir l'apparition de la congestion " Mesures préventives 18

8 Notification de la congestion! Faite par le routeur! Le feedback dépend de l'intelligence du routeur " Rien faire pour prévenir la congestion (PQM) " Notification implicite binaire " Anticiper la congestion (AQM) " Sans notification binaire explicite à la source " Avec notification binaire explicite à la source " Allouer un débit adapté à la source (par un contrôleur) " Notification explicite à la source de la BW disponible 19 Discipline de service! Objectif " Isoler les trafics! Principe " La discipline de service est une fonction d'ordre de service (transmission) des différents paquets " Qui est le prochain paquet transmis? " Contrôle l'usage de la bande passante par flots " Affectation d'un débit " Traite un délai " S'applique sur différentes granularités du flot " Flot applicatif " Agrégation de flots " Effectue une gestion de la bande passante avec état! 2 approches " Work-conserving " jamais au repos si des paquets attendent " Non work-conserving " retarde le service du paquet jusqu'à ce qu'il soit éligible 20

9 ! Introduction! Passive Queue Management! Active Queue Management! Notification explicite Plan 21 PQM! Gestion déterministe de la file d'attente " La file d'attente a une longueur maximum " Accepte les paquets jusqu'à la longueur maximum soit atteinte " Tant que la file d attente est pleine : élimine des paquets quand des nouveaux paquets arrivent 22

10 Quel paquet jeter?! Drop from tail " Par défaut " Pertes de paquets entrants dans la file d'attente " Très simple à mettre en œuvre : pas de modification des pointeurs de la file! Drop from front " Perte du paquet le plus vieux " Plus complexe à mettre en œuvre : les paquets sont de longueur variable! Random drop " Expulsion d'un paquet choisi au hasard pour faire la place au paquet entrant " L'idée: " probabilité de sélectionner un paquet d'un flot en proportion son usage de la BP Keshav 23! Cas de 2 sources TCP " Performance vue au niveau des hôtes Drop Tail 24

11 Pour la Source: principaux défauts! Synchronisation des sources " Plusieurs paquets perdus " Les sources sont informées en même temps (au RTT près) de la congestion " La charge diminue fortement (sur-réaction) " Risque de sous utilisation du lien! Pertes par rafales " Mauvaise performance du fast recovery " Biais contre les sources sporadiques " Taux de perte important pour les trafics sporadiques " Chute importante du débit 25! Cas de 2 sources TCP " Performance vue au niveau du réseau Drop Tail 26

12 Une file pleine E Lochin 27 Effet de phase! Effet de phase : " Provoque une répartition inéquitable des ressources " Très présent lors des simulations! La phase φ" " Ecart entre le départ et l'arrivée d'un paquet au niveau du routeur du goulot d'étranglement! La source est en phase " Quand ses arrivées correspondent aux départs des paquets au niveau du routeur Floyd, S. et Jacobson, V. (1992). Internetworking: Research and Experience, Vol. 3, No. 3, pp " On Traffic Phase Effects in Packet-Switched Gateways.! 28

13 Effet de phase 3sources TCP RTT différents Cas normal Avec effet de phase 29 Pour le réseau: principaux défauts! Instabilité de la file d'attente " Variation importante de la longueur de la file d'attente " La file d'attente peut passer de l'état plein à l'état vide - Le taux d'utilisation de la BP chute - introduit une forte gigue! Maintient la file d'attente pleine " Signalisation tardive de la congestion (1 RTT après la perte + temps de traversé des paquets suivant le paquet perdu) " La file reste pleine tant que les sources n'ont pas appris la congestion (créant potentiellement d avantage de pertes) " Répercussions en terme de délai! Partage inéquitable " La bande passante est allouée en proportion du taux d'occupation de la file " Favorise les flots non élastiques i.e. ceux qui ne réduisent pas leur débit et qui ont pu remplir la file quand elle était vide " Effet de phase [1] " Une simple connexion peut monopoliser la file d'attente [1] Floyd, S. et Jacobson, V. (1992). Internetworking: Research and Experience, Vol. 3, No. 3, pp " On Traffic Phase Effects in Packet-Switched Gateways.! 30

14 Améliorations! Drop from front " Améliore le fast retransmit " Détection de la perte plus rapide (gain: temps d'attente de la file) " Meilleur distribution des pertes " Améliore l'équité " Supprime l effet de phase! Random drop " Introduire de l'aléatoire dans le réseau " Traite la synchronisation des sources et l'effet de phase " Supprime la "résonance" entre le routeur et la source " Améliore l'équité # Cependant la file reste pleine la majorité du temps " La congestion est détectée 1 RTT après qu elle ai commencée " La détecter plus rapidement serait mieux mais pas suffisant " Il faut anticiper la congestion 31! Introduction! Passive Queue Management! Active Queue Management! Notification explicite " ECN " ERN Plan 32

15 ! Principe de l AQM " Anticiper l'apparition de la congestion AQM! Avantages attendus " Augmenter le taux d'utilisation des liens " Diminuer les pertes " Répartir les pertes dans le temps " Améliorer l'équité entre les flots " Réduire le temps moyen d'attente! "Cahier des charges" " Agir tout en évitant de pénaliser les flots sporadiques " Eliminer la synchronisation des sources TCP " Distinguer la congestion transitoire de la congestion persistante 33 AQM! Principe " Détection de l'apparition de la congestion " Mesurer le niveau de congestion " Seuil pour commencer à traiter les paquets " Sélection probabiliste un paquet " Fonction du niveau de la mesure de congestion " Notification de la congestion à la source " Jette un paquet même si la file n'est pas pleine (early drop) " Envoie d'une notification de réduction du débit à la source (marquage) 34

16 Early Random Drop! Principe " Elimine les paquets avec une probabilité fixée quand la file d'attente à atteint un seuil! Ne fonctionne pas " Ne reflète pas le trafic moyen " Pénalise les flots sporadiques " Ne distingue pas les congestions transitoires (les rafales) des congestions sévères 35 RED (Random Early Discard)! Améliorations de ERD " Détection de congestion: moyenne flottante de la longueur de la file " Les petites rafales (de TCP) passent de manière transparente " Agit sur les congestions dues à des surcharges " Probabilité de perte est une fonction croissante de la longueur moyenne de la file d'attente " Action proportionnelle à la congestion P(mark) 1 Pmax minth Maxth Avg Floyd, S. et Jacobson, V. (1993). IEEE/ACM Transactions on Networking, Vol. 1, pp , August." Random Early Detection Gateways for Congestion Avoidance.! 36

17 Algorithmes! Calcul de la longueur moyenne: EWMA " La pondération sert à déterminer le degré de sporadicité toléré Avg = (1 w). Avg + w.qlen! Calcul de la probabilité de perte " En fonction de 2 seuils (Min_Th, Max_Th)! RED Pour chaque paquet reçu! calculer la taille moyenne de file avg! si minth avg maxth! calculer la probabilité p(avg)! avec la probabilité p(avg)! marquer/détruire le paquet! sinon si avg > maxth! détruire le paquet! Max_th! P(mark) average! 1 minth Min_th! Pmax Maxth Avg A. Duda 37 Cwnd DropTail RED 38

18 Flot TCP DropTail RED 39 File d'attente DropTail RED 40

19 RED E Lochin 41 Evaluation de RED! Amélioration de l'efficacité du réseau " Désynchronisation des sources! Amélioration du fonctionnement de TCP " Corrige partiellement l'inéquité vis à vis du RTT " La probabilité de choisir un flot est proportionnelle au débit du flot. " Produit plutôt des pertes simples: récupération par un fast retransmit! Diminue le délai d'attente " Tendance à conserver une longueur de file d'attente plus faible 42

20 Arguments contre RED! Paradoxe de la solution " Pourquoi jeter des paquets pour améliorer les performances des sources?! Instabilité de la longueur de la file d'attente " Lors des changements de conditions de trafic! Paramétrage (trop) difficile " Dépend du trafic! Solutions " Configuration automatique: ARED " Adaptive RED / Gentle RED " Marquage des paquets: ECN Floyd, S.; Gummadi, R. et Shenker, S. (2001)." Adaptive RED: An Algorithm for Increasing the Robustness of RED s Active Queue Management.! 43 Quelques autres AQMs! Une littérature très fournie selon deux types de propositions " Contrôle de l'agrégat " Traite le problème de la stabilité " Contrôle par flot " Traite le problème d'inéquité! Exemples " Adaptive Virtual Queue (AVQ) " Proportional Integral (PI) " Dynamic-RED (DRED) " Random Exponential Marking (REM) " Blue " CHOKe " Et bien d autres Kunniyur, S. et Srikant, R. (2001), SIGCOMM." Analysis and Design of an Adaptive Virtual Queue (AVQ) Algorithm for Active Queue Management.! Hollot, C.V.; Misraz, V.; Towsley, D. and Gong, W.B. (2001). Infocom. " On Designing Improved Controllers for AQM Routers Supporting TCP Flows." Aweya, J.; Ouellette, M. et Montuno, D.Y. (2001). ACM International Journal of Network Management, Vol. 36, July." A control theoretic approach to active queue management.! Athuraliya, S.; Low, S.H.; Li, V.H.et al. (2001). IEEE Network, May." REM: Active Queue Management.! Feng, W.-c.; Kandlur, D.D.; Saha, D.et al. (1999)." BLUE: A New Class of Active Queue Management Algorithms.! Psounis, K.; Pan, R.; Prabhakar, B. (2001)." APPROXIMATEFAIR DROPPING FOR VARIABLE-LENGTH PACKETS.! 44

21 ! Introduction! Passive Queue Management! Active Queue Management! Notification explicite " ECN " ERN Plan 45 Perte dans un flot court! Performance dépend du taux de perte " Une perte est significative sur le taux de perte! Avec Limited Transmit " Peut demander jusqu'à 2 RTT supplémentaires avant d'enclencher le Fast Retransmit Limited transmit Fast Retransmit 46

22 Explicit Congestion Notification (ECN)! Objectifs " Réduire les pertes induites par le réseau " Couplé à une AQM : anticipation de la congestion! Idée: " Notification explicite de la congestion " Routeurs marquent des paquets quand leur file d'attente est presque pleine! Avantages attendus " Pas de retransmission " Efficacité " Délai plus faible pour les applications interactives " Notification plus rapide de la congestion " Pas d'attente de 3 dup ack " Pas d'attente du temporisateur de retransmission " Réduction du taux de pertes dans le réseau " Performance pour les flots courts 48 Résultat 49

23 RED vs ECN E Lochin 50 Limitations d'ecn! Les paquets marqués peuvent être détruits! certains récepteurs peuvent ne pas tenir compte du marquage " Proposition RFC 3540 ECN-nonce! Problème majeur: déploiement " Les sources doivent être modifiées pour interpréter les marques " Sur 2% des serveurs seulement!!!! " Des effacements des bits ECN par middle-boxes " Peu de configuration RED/ECN des routeurs! Reste le problème de l'oscillation de la file d'attente " Notification binaire de la congestion! N'améliore pas le fonctionnement de TCP dans les LFN " Adapté pour l'internet du futur? Briscoe, B. (2009). Internet: Fairer is Faster: A complete overhaul of how we share Internet capacity is in progress.! " 51

24 ! Introduction! Passive Queue Management! Active Queue Management! Notification explicite " ECN " ERN Plan 52 Explicit Rate Notification (ERN)! Objectifs " Diminuer le temps de réponse pour améliorer la performance " Débit écoulé " Taux de pertes " Minimiser les oscillations : autour du débit disponible / de la taille de la file d attente " Renforcer l'équité entre les flots! Principe " Les routeurs déterminent l'allocation des flots " La notification n'est plus binaire mais un taux d'émission pour la source " La source ajuste son débit à celui indiqué par la notification Paquet Calcul de la notification Source Destination ACK 53

25 Quick-Start! Problème " Le temps du Slow Start est long pour les petits flots " Exemple: pour cwnd=n ( log 2 N 2).RTT! Idée " Découvrir le débit de démarrage par une Interaction transport-réseau " Notification de sous utilisation des liens! Principe " La source propose un débit d'émission " Chaque routeur approuve, dégrade ou désapprouve la demande " Le récepteur envoie en écho la requête RFC 4782 " La source démarre en quick-start si sa demande n a pas été désapprouvée, autrement elle démarre normalement (Slow Start pour TCP) " La fenêtre est initialisée: cwnd = rate RTT! Evaluation " Amélioration proportionnelle au délai*bp " Difficulté de mise en œuvre (routeur et hôte) " Expérimental (Janvier 2007) 54 XCP (explicit Congestion control Protocol)! Principes " L'émetteur propose une augmentation " Les routeurs dégradent cette proposition en fonction de leur capacité disponible par flot! Fonctionnement " Congestion header " Emetteur ajuste sa fenêtre à chaque notification " Routeurs calculent la notification en 2 étapes: " Efficiency Controller : pour l'agrégat " Fairness Controller : pour le flot. s: segment size Katabi, D.; Handley, M. et Rohrs, C. (2002), SIGCOMM." Congestion Control for High Bandwidth-Delay Product Networks.! 55

26 Congestion Header cwnd current: 100 rtt current feedback: +50 Illustration Congestion Header cwnd current: 100 rtt current feedback: +50 Congestion Header cwnd current: 100 rtt current feedback: +20 Sender sets feedback to be desired increase in cwnd. Router allocation > desired cwnd. Therefore, no change to feedback Router allocation < desired cwnd. feedback updated to = +20 Sender Receiver Router allocation: 200 bytes per flow per average RTT Router allocation: 120 bytes per flow per average RTT Receiver copies feedback from bottleneck router into ACK to sender. Joe Bannister" 56 Résultat From Katabi, D.; Handley, M. et Rohrs, C. (2002), SIGCOMM." Congestion Control for High Bandwidth-Delay Product Networks.! 57

27 Comparison of XCP and TCP Avg. Utilization Avg. Utilization Bottleneck Bandwidth (Mb/s) Round Trip Delay (sec) From 58 Evaluation! Avantages " Ne perd pratiquement aucun paquet " Converge rapidement à la bande passante disponible (~1 RTT) " Equitable! Etat " Travaux de recherche " Pas de mise en oeuvre " orienté réseaux avec liens par satellites! Limitations " Problème de déploiement " Changer les routeurs " Changer les hôtes " Problème de motivation " Equité inter-flot 59

28 En résumé! La discipline d'attente est un élément essentiel dans le service best effort " En cas de congestion, il faut jeter des paquets! Le routeur a un rôle de notification! Les routeurs doivent avoir un AQM (RFC 2309) " AQM par défaut : RED " RED pour améliorer le fonctionnement des sources élastiques " Par une meilleure interaction réseau - TCP " n'est pas parfait mais mieux que DropTail au pire est égal à DropTail! Notifications explicites ECN / ERN " ECN réduit les pertes et améliore la stabilité " Notification binaire -> la file d attente oscille toujours " ERN : Peu de pertes, beaucoup plus stable " Problèmes de mise et œuvre et de cohabitation avec l existant! Le contrôle de congestion, c'est l'affaire " Du transport pour adapter le débit d'émission " Du réseau " Pour envoyer une notification appropriée (dans le temps et au flot) " Pour isoler les flots malveillants! UNE difficulté: la latence de la boucle de contrôle (RTT) 60 Limitation de la discipline d'attente! Aucune protection " Un flot peut baver sur les autres flots 10 " Exemple UDP vs TCP! Solution " Isoler les flots: séparer les flots dans des files d'attente différentes " Discipline de service UDP Throughput(Mbp s) RED Flow Number Discipline de Service TCP Nagle, J. (1987). IEEE Transactions on Communications, Vol. 35, No. 4, pp , April." On Packet Switches with Infinite Storage.! Stoica 61

29 AQM vs Scheduling 1 UDP (10 Mbps) 31 TCPs sharing Un goulot d'étranglement à 10 Mbps UDP (#1) TCP (#2). TCP (#32) 10 Mbps) UDP (#1) TCP (#2). TCP (#32) Throughput(Mbps) Stateless solution: Random Early Detection (RED) Flow Number Throughput(Mbps) Stateful solution: Fair Queueing Flow Number Stoica 62 En résumé - 2! La priorité spatiale (nombre de paquets d un flot dans la file d attente) sert en contrôle de congestion! La priorité temporelle vise à fournir une isolation entre les flots! RED est destiné à améliorer l'interaction réseau - TCP! Un AQM discrimine le taux de pertes des paquets! FQ (WFQ) utilise la bande passante en excès (work conserving)! Le WFQ sert à allouer un débit dans les réseaux de paquets " Garantie de débit minimum offerte! Remarque : Une borne de délai est possible si le flot est régulé " Le délai dépend du débit alloué " Ces problématiques seront traitées dans les UE MMQos et TCONT 63