Dimensionnement des buffers pour les routeurs IP de cœur de réseau

Le contrôle de congestion dans l’Internet repose principalement sur les mécanismes implémentés par TCP, auxquels s’ajoute une limite au débit des flots imposée par les débits d’accès. La perfor- mance des flots, et notamment du contrôle effectué par TCP, nécessite un dimensionnement correct des buffers au sein des routeurs de cœur de réseau, qui sont gérés en FIFO. La règle empirique de dimensionnement traditionnellement utilisée – dite du Bandwidth Delay Product (BDP) – montre ses limites avec l’accroissement constant des capacités des liens, et les contraintes techniques qui limitent la taille des buffers. D’abord mis en évidence par l’article de Appenzeller et al. [7], le problème du dimensionnement a depuis suscité une attention croissante. Dans ce chapitre, nous examinons le problème au vu de notre compréhension des caractéristiques du trafic, et de la performance du partage de bande passante statistique. Nous montrons au moyen d’un modèle analytique simple couplé aux résultats de simulations ns2 que, tandis qu’un buffer de taille équivalente au BDP n’est pas forcément nécessaire, la proposition récente de les réduire à quelques dizaines de paquets est certainement trop drastique. La taille nécessaire pour le buffer dépend de manière significative du débit crête exogène des flots multiplexés.

Le dimensionnement des buffers au sein des routeurs a reçu beaucoup d’intérêt récemment [7, 129, 163, 128, 49, 3, 2], avec notamment la remise en cause de la règle empirique dite du Bandwidth Delay Product initialement proposée par Villamizer et al. [149]. La réalisation de grand buffers est un défi technique pour des liens ayant des débits de plusieurs dizaines de gigabits par seconde. C’est un but pour l’instant inaccessible pour des routeurs purement optiques qui constitueront vraisemblablement la prochaine génération d’équipements. La pertinence de cette règle empirique est remise en cause au vu de l’évolution des capacités des liens de cœur de réseau et du volume de trafic transporté. Il serait par exemple moins coûteux d’accepter de sacrifier un petit pourcentage de l’utilisation, quitte à prévoir un supplément de bande passante. Lors des périodes de congestion, le lien est utilisé à 100% et des paquets s’accumulent dans le buffer. Comme nous l’illustrerons dans le chapitre suivant, sans différenciation, la présence de buffers importants est une source de délais et de gigue pour les flots streaming, aggravée par les émissions en rafales des flots TCP. Réduire la taille des buffers permettrait de mitiger ces problèmes. Les consé- quences d’une telle réduction sur la performance du trafic élastique restent un sujet d’étude, auquel nous consacrons une grande partie de ce chapitre. Néanmoins, un dimensionnement correct de ces buffers n’éliminera pas les pertes de paquets subies par les flots lors des instants de saturation du buffer causés par des rafales.

Avrachenkov et al. [9] présentent une analyse des performances de TCP en fonction de la taille du buffer. Une analyse par point fixe à partir d’un modèle assez complexe de TCP conclut sur l’inefficacité de buffers soit trop petits, soit trop grands. Elle est confirmée par des simulations ns-2. Si l’on se réfère à l’explication donnée précédemment pour justifier la règle du Bandwidth Delay Product, un buffer trop petit ne permet pas à TCP d’utiliser la totalité de la bande passante disponible (pendant les périodes où il n’émet pas de paquets), et il causera un fort taux de pertes étant souvent saturé. Réciproquement un buffer surdimensionné sera rarement vide et allongera les délais subis par les paquets, d’autant que la majorité des flots qui sont contraints par leur débit d’accès n’en profiteront pas. La règle du Bandwidth Delay Product nécessite de connaître le RTT moyen des flots sur le lien,qui n’est pas facile à caractérise. Les effets d’un sous-dimensionnement étant considérés plus graves (utilisation du lien, équité entre les flots) que ceux d’un surdimensionnement, il est fréquent de prendre une valeur moyenne pour le RTT de 200 à 250ms (de l’ordre du temps de propagation transatlantique).