Agir dans le réseau est la proposition la plus difficile à mettre en œuvre. Bien que nous avons la certitude que la conception d’un mécanisme qui managerait de façon optimale la capacité réseau tout en offrant une équité intra et inter-flots ne peut être réalisée sans collabo-ration de ce dernier [14, 16], les propositions impliquant le cœur du réseau ne sont générale-ment pas déployées.
Ce chapitre présente cependant trois contributions distinctes qui pourraient, pour cer-taines, être déployées de façon incrémentale.
Introduction
L’étude des files d’attente actives (AQM : Active Queue Management) a occupé la com-munauté réseaux des années 90 qui avait investi un effort considérable dans ces algorithmes. Le but ciblé était d’offrir aux opérateurs réseaux une méthode simple en vue d’obtenir des délais de traversée rapide et d’atteindre de haut débits. L’idée était de détecter la congestion avant qu’elle ne se produise effectivement dans le réseau et deux méthodes avaient alors été envisagées :
1. soit jeter les paquets, obligeant implicitement les sources TCP à réagir ;
2. soit marquer le bit indicateur de congestion ECN (au lieu de jeter les paquets) afin de solliciter une réaction de la source TCP.
Nous ne reviendrons pas sur les débats qui avaient animé la communauté scientifique sur l’invraisemblance de jeter des paquets pour prévenir la congestion et sur le refus de la politique de rejet inhérente à l’AQM RED [27]. En effet, nombreuses sont les études qui ont montré que RED était fondamentalement difficile, voire impossible à mettre en œuvre [26] et très instable [25] [24].
Il existe cependant un amalgame entre la solution RED/Dropping et la solution RED/ECN qui reste synonyme de mauvaises performances et d’infaisabilité. Pourtant, des études mon-trent les atouts indéniables des bénéfices apportés par une indication explicite de conges-tion vers les extrémités. En effet, Sally Floyd en 1994 avait déjà montré que cette indicaconges-tion permet–tait d’augmenter considérablement les performances du système [15]. Dans [22], les auteurs font la même constatation sur le trafic web et encore plus récemment en 2005, Alek-sandar Kuzmanovic dans "The Power of Explicit Congestion Notification" [28] reconsidère la pertinence du marquage ECN et démontre que les terminaux qui utiliseront ECN dans l’in-stant, bénéficieront de performances accrues et immédiates et ce, sans avoir besoin d’attendre que la communauté Internet se décide à supporter définitivement ce choix.
Malgré le poids de ces arguments, l’étude suivante [29] précise que ECN n’est utilisé que par 2,1% des hôtes en 2004. Pourtant, bien que ECN soit relativement bien implémenté aussi bien dans les extrémités (dans les systèmes GNU/Linux, MacOSX et Windows) que dans les éléments de cœur du réseau (le système IOS des routeurs Cisco propose une variante de RED/ECN nommée WRED/ECN), cette option reste désactivée par défaut. Concernant les extrémités, c’est assez paradoxal. Alors qu’aujourd’hui des variantes de TCP non stan-dardisées telles CUBIC ou Compound sont proposées par défaut (respectivement au sein de systèmes GNU/Linux et Windows Vista), soulevant de nombreux débats concernant leur équité avec la version TCP Newreno standard, un mécanisme prouvé et standardisé comme ECN ne l’est pas.
Cette absence de déploiement pourrait s’expliquer en deux points :
1. les paramètres de configuration de RED sont très difficiles à déterminer. Même lorsque cela est possible pour des hypothèses données, il restent très peu généralisables ; 2. la tâche ingénieuriale de mise en œuvre d’un tel mécanisme au sein de l’Internet est
complexe.
Il est également important de noter que ce pourcentage assez faible s’explique aussi par les pare-feux et autres middle-boxes de l’Internet qui réinitialisent généralement (et sans jus-tification concrète) une connexion TCP utilisant le drapeau ECN [28]. Cela ne plaide pas en la faveur de certaines architectures clean slate qui proposent de révolutionner l’Internet avec des solutions qui semblent difficilement déployables sur une courte échelle temporelle. De plus, ces architectures peuvent rentrer en conflit avec certains intérêts économiques et légaux (voir notamment l’argumentation des "Tussle" de l’Internet [17]).
Dans un contexte plus privatif, il est à noter une proposition protocolaire pour Data Cen-ter se basant sur ECN afin de réduire le délai de traversée des files d’attentes de routeur [10]. En effet, bien que les réseaux sur-provisionnés, possédant de grandes capacités de bufferisa-tion, permettent de réduire le taux de pertes, ces derniers ne permettent pas de minimiser le délai. Le tout récent protocole DCTCP [10] proposé par Microsoft utilise donc un marquage particulier basé sur ECN afin de réduire la taille des buffers des routeurs.
Ce chapitre présente trois contributions qui cherchent à agir au sein du réseau de cœur. La première nommée KRED, cherche à résoudre le premier point en vérifiant si l’intuition de Sally Floyd, et notamment la configuration complexe des paramètres de RED peut être solutionnée à l’aide des réseaux neuronaux. La seconde, ECN*, se trouve en marge de ces points et propose d’améliorer la lisibilité par ECN du niveau de la congestion d’un chemin du réseau. Enfin, Favour-Queue, qui est une file d’attente sans état, autonome, sans configu-ration initiale et facilement déployable, propose une alternative concrète aux performances du trafic et en particulier des flots courts.