Plan. Contrôle de trafic dans les routeurs

Transcription

1 ! Motivations! Disciplines d'attente! Disciplines de service Plan Contrôle de trafic dans les routeurs Pascal Anelli Université de la Réunion 2 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! Traitements des paquets " Ordre de transmission (Scheduling) " Mise en file d'attente (Queue Management) Modèle de routeur Contexte du bout en bout " Les états relatifs aux flots sont dans les hôtes " Donc le contrôle de congestion est dans les hôtes - Il faut une notification du réseau (feedback)! Contrôle de congestion de l'internet " Repose sur une allocation décentralisée des ressources par - Une notification du réseau - Une réaction de la source! La congestion est dans les routeurs " Gestion de leurs ressources! 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) Traitement des paquets # Est ce suffisant? 3 Gevros, P.; Crowcroft, J.; Kirstein, P.et al. (200). IEEE Network, Vol. 5, No. 3, May. Congestion Control Mechanisms and the Best Effort Service Model. 4

2 Gestion des ressources " Mettre de l'"intelligence dans le routeur" " Prendre un rôle actif dans le contrôle de congestion en complément de celui de E2E! Motivations " Partage équitable " Améliorer le fonctionnement du contrôle de congestion de TCP " Maintenir un taux d'utilisation des liens importants " Des délais de transfert faibles! Ne traite pas " Du congestion collapse! Motivations! Disciplines d'attente! Disciplines de service Plan 5 6 Discipline d'attente! Objectifs " Essayer d'améliorer le service best effort par le contrôle de la file d'attente de multiplexage - Importance du tampon mémoire dans la performance de TCP " Ne fournit pas un nouveau service aux applications " Contrôle sur la congestion par le contrôle de la longueur de la file d'attente " Gestion de la file d'attente -> Un paquet à jeter : lequel et quand " Produit le feedback à la source " Gestion des tampons mémoires - sans état - 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: congestion et pertes de paquets " Active (Active Queue Management) - Action en phase de congestion avoidance - pour prévenir l'apparition de la congestion - Mesures préventives 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 " Elimine les paquets quand des nouveaux paquets arrivent jusqu'à ce que la longueur diminue 7 8

3 Quel paquet jeté? (drop position)! Drop from tail " Par défaut " Pertes de paquets entrants dans la file d'attente " Très simple à mettre en oeuvre: pas de modification des pointeurs de la file! Drop from front " Perte du paquet le plus vieux " Améliore le fast retransmit - Détection de la perte plus rapide (gain: temps d'attente de la file) " Plus complexe à mettre en œuvre! Cas de 2 sources TCP " Performance vue au niveau des hôtes Drop Tail! Random drop " Expulsion d'un paquet choisi au hasard pour faire la place au paquet entrant " Idée: prob de sélectionner un paquet d'un flot en proportion de l'usage de la BP Keshav 9 0! Au niveau du réseau Exemple Drop Tail Défauts de Drop tail! Partage inéquitable " La bande passante est allouée en proportion du taux d'occupation de la file - Favorise les flots non élastiques " Effet de phase [] - Une simple connexion peut monopoliser la file d'attente! Maintient la file d'attente pleine " Signalisation tardive de la congestion, " La file reste pleine tant que les sources n'ont pas apprises la congestion " Répercussions en terme de délai! Effet de synchronisation entre les flots TCP " Plusieurs paquets perdus " Plusieurs sources détectent la congestion et entre en reprise en même temps " Grande variation de la longueur de la file d'attente -> forte gigue " Risque de sous utilisation du lien! Pertes par rafales " Mauvaise performance du fast recovery " Taux de perte est important pour les trafics sporadiques [] Floyd, S. et Jacobson, V. (992). Internetworking: Research and Experience, Vol. 3, No. 3, pp On Traffic Phase Effects in Packet-Switched Gateways. 2

4 Améliorations! Drop from front " Meilleur distribution des pertes - Améliore l'équité! 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 " Il faut anticiper la congestion! Objectif " Anticiper l'apparition de la congestion " Détecter l'apparition de la congestion - Seuil pour commencer à traiter les paquets " Elimination anticipée du paquet (early drop) - Jeter un paquet même si la file n'est pas pleine AQM - Envoie d'une notification de réduction du débit à la source avant la congestion " Actions à la mise en file d'attente - Suppression du paquet (RED, ) - Notification explicite (ECN) par marquage du paquet! Autres objectifs " Débit écoulé important - Augmenter le taux d'utilisation des liens " Diminuer les pertes " Délai d'attente moyen faible " Améliorer l'équité entre les flots! Comment " Eliminer la synchronisation des sources TCP " Distinguer la congestion transitoire de la congestion persistante " Éviter les pertes en rafale " Agir tout en évitant de pénaliser les flots sporadiques 3 4 Early Random Drop " Elimine les paquets avec une probabilité fixée quand la file d'attente à atteint un seuil RED (Random Early Discard)! Améliorations de ERD " Détection de congestion: moyenne flottante de la longueur de la file - Les petits 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! 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 5 Floyd, S. et Jacobson, V. (993). IEEE/ACM Transactions on Networking, Vol., pp , August. Random Early Detection Gateways for Congestion Avoidance. 6

5 Algorithmes! Calcul de la longueur moyenne " EWMA " La pondération sert à déterminer le degré de sporadicité toléré! Calcul de la probabilité de perte " En fonction de 2 seuils (Min_Th, Max_Th) DropTail Exemple RED RED! RED Max_th average Min_th Pour chaque paquet reçu calculer la taille moyenne de file avg si minth! avg! maxth calculer la probabilité p(avg) avec une probabilité p(avg) marquer/détruire le paquet sinon si maxth < avg détruire le paquet A. Duda 7 8 DropTail Exemple RED RED! Au niveau du réseau DropTail Exemple RED RED 9 20

6 Explicit Congestion Notification! Motivations " Notification explicite du réseau - Eviter les pertes " Pour le trafic interactif, le service est sensible à la perte " Notification plus rapide de la congestion - Pas d'attente de 3 dup ack - Pas d'attente du temporisateur de retransmission " Notification par la perte - Inefficacité - Retransmission! ECN repose sur un AQM " RED avec marquage! Limitations: " les paquets marqués peuvent être détruits " Les sources doivent être modifiés pour interpréter les marques " certaines sources peuvent ne pas tenir compte du marquage " Déploiement progressif RFC 368 En résumé! 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! Le paramétrage difficile " Dépend du trafic: élément dynamique " Proposition: A-RED Floyd, S.; Gummadi, R. et Shenker, S. (200). Adaptive RED: An Algorithm for Increasing the Robustness of RED s Active Queue Management.! Recommandé comme AQM pour Internet " RFC 2309 # Pas parfait mais mieux que DropTail Au pire est égal à DropTail 2 25! Aucune protection " Un flot peut baver sur les autres flots " Exemple UDP vs TCP! Solution Problème restant avec RED RED Flow Number Throughput(Mbp s) " Isoler les flots:séparer les flots dans des files d'attente différentes " Discipline de service! Motivations! Disciplines d'attente! Disciplines de service Plan Nagle, J. (987). IEEE Transactions on Communications, Vol. 35, No. 4, pp , April. On Packet Switches with Infinite Storage

7 Ordonnanceur! Définition " La discipline de service est une fonction d'ordre de service (transmission) des différents paquets - Qui est le prochain paquet transmis? " Affectation d'un débit " Traite un délai Classification des disciplines de service! Work-conserving " jamais au repos si des paquets attendent " loi de conservation: - Délais sont constants, l'ordonnancement alloue les délais N "! i d i = Cst Avec i =! Non work-conserving " Peut être au repos même si des paquets attendent " Retarde le service du paquet jusqu'à ce qu'il soit éligible! Évaluation " A conservation - Introduit des déformations: Grumeaux - Augmentation de la taille des files d'attente " Non conservation - Maintient l'aspect du trafic (gigue) - Limite le besoin de tampons - Oblige la source à respecter son descripteur FIFO 3 32 Rappel: FIF0! Partage de la bande passante " Proportionnellement au trafic offert! Aucune isolation " Flot adaptatif / flot non adaptatif - Partage non équitable " Flot à données temps-réel/ flot à données discrètes - Délai important " Ordre de service selon une classe de priorité " une file FIFO pour chaque classe de priorité " L'ordre de service des files suit l'ordre des classes de priorité - Un paquet d'une classe de priorité est servi si les files d'attentes des classes de priorité supérieure sont vides " Aucune préemption Priority queue + Priorité forte Priorité + - protection Priorité moyenne Priorité faible - 33 Roch Guérin 34

8 Priority queue! Evaluation " Simple " La priorité la plus forte obtient le délai le plus faible " Protection entre les classes mais unidirectionnelle - Urgent n'est pas perturbé par BE " Risque de famine pour les priorités inférieures - Comment empêcher l'utilisation du trafic à priorité? - Il faut un CAC et un contrôle d'accès à l'exception du niveau de priorité le plus faible " Pas d'isolation entre les flots dans une classe - Pas de garantie de débit ou de délai possible - Inéquité Tourniquet (Round Robin) " Parcourir les files d'attente non vide et servir un paquet pour chaque file " WRR (Weighted Round Robin) - servir une file en fonction de son poids! Évaluation " Isolation entre les flots - Pas de famine Classification: Par classe!par flot - Pénalise les flots non réactifs: pertes et délais important " Inéquité en bits - Équité comptée en paquets: Paquets sont de taille variable et les flots avec des gros paquets obtiennent plus. " Pas d'allocation de la bande passante (en bits/s) - Pas de garantie de débit ou de délai Earliest Deadline First (EDF) " Définit une méthode d'ordonnancement " Ordre de service des paquets selon une estampille temporelle " Estampillage des paquets à leur arrivée en fonction de leur contrainte - Les paquets avec des contraintes de délai ont une estampille avec une valeur faible D i k = A k + d i - d i délai alloué au flot i " Plusieurs algorithmes pour la détermination de l'estampille Fair Queuing! Objectif " Partage équitable de la transmission - équité max-min " Emulation du modèle fluide pour chaque flot " Service du modèle fluide " Service selon un round robin par flots " Unité de service infinitésimale - Service des flots en // - Service idéal et non réalisable " Service reçu dépend du nombre de flots actifs - Attention: " du nombre de paquets Arriving packets Tagging unit Sorted packet buffer Packet discard when full Transmission link 37 Service fluide 38

9 Partage Max-min! Objectifs " Avoir le maximum de flots satisfaits dont ceux qui demandent le minimum " Augmenter l'efficacité du réseau s " Satisfaire ceux qui demandent le moins " Allocation dans l'ordre croissant des demandes " Personne n'obtient plus que sa demande " Tous ceux qui n'ont pas leur demande satisfaite ont une allocation égale Partage égalitaire de l'excédent Demande non satisfaite Flot à t=0 flot 2 à t=0 flot à t=0 Données Par flot Données Par flot 2 0 FQ avec des paquets /2 Modèle fluide service Fin de service t 2 Données Par flot 2 0 attente Modèle paquet 2 t A B C A B C! Définition " Soit le vecteur d'allocation X est équitable max-min si il existe un autre vecteur y tel que: pour le flot j y j > x j impliquant qu'il existe un flot i tel que y i <x i < x j " "Personne ne peut avoir plus au prix d'une diminution de quelqu'un qui a déjà moins" Keshav 39 flot 2 à t=0 0 /2 2 3 t attente t Leon-Garcia 40 " Estampiller chaque paquet avec l'instant de transmission du dernier bit: fin de service " Servir les paquets dans l'ordre croissant de leur fin de service! Fonctionnement k " Soit l'estampille de fin de service pour le paquet k du flot i : F i Avec F i k = S i k + L i k S k k i = max F! k ( i, A i ) Début du service Fair Queuing où A i k = R(a i k ) Instant d'arrivée Service reçu par flot Compteur R(t)! Compteur du "service" " Représente l'avancement du service exprimé en bit pour chaque flot actif " Chaque flot reçoit un service de un bit par cycle - cycle = tour de service pour chaque flot actif! Compteur de cycles de service - avance d'une unité quand tous les flots actifs ont été servis d'une unité de service " La durée d'un cycle est proportionnelle au nombre de flots actifs. La transmission est terminée L cycles plus tard cycles # de cycles Un paquet de longueur L bits commence sa transmission à cette instant! Quand commence la transmission du paquet k? " Si le paquet k- du flot i n'a pas finit son service - Immédiatement après à la fin du paquet k- " Si il n'y a pas de paquet en cours de service pour le flot i k - Dès qu'il arrive à l'instant a i 4! Corollaire " Un flot est actif (backlogged) tant que : F i k > R(t) 42

10 Temps Virtuel du système! R(t) peut être interprété comme un temps virtuel: V(t) " Mesure du service en modèle fluide! Pente de V(t): débit du service fournit à chaque flot actif " Service reçu par chaque flot " Dépend du nombre de flots actifs N(t)! Cas étudié " Service : unité/sec " 3 flots Exemple - Entrée Sortie 2 u! V (t)! t = N(t) Service fluide Stoica Fair Queuing: Caractéristiques! Maintient de l'activité (work-conserving) " Le service reçu peut être plus favorable si le nombre de flots actifs est faible S i (!,t) " t #! N C! Combinaison avec une discipline d'attente " Exemple: file par flot --> isolation complète En résumé! RED, un AQM pour améliorer le fonctionnement des sources élastiques " Par une meilleure interaction réseau - TCP! FQ améliore le partage du lien! Discipline de service n'élimine pas la congestion " n'empêche pas le congestion collapse " Elles ne fait que gérer la congestion! En cas de congestion, il faut toujours jeter des paquets " Gestion de la file d'attente est nécessaire à ce moment Packet flow Packet flow 2 Packet flow n Service round robin avec EDF C bits/second Transmission link! 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) 45 46