Le modèle Best-Effort actuel et ses limites

Réseau Best Effort et ordonnancement FIFO/DropTail 

Le principe fondateur de l’Internet est d’offrir un réseau, fondé sur la brique IP, qui offre une connectivité de bout en bout sans aucune garantie de service [45]. On parle de réseau Best Effort. Les routeurs effectuent un routage simple des datagrammes IP en utilisant des files d’attente FIFO (First In First Out), dans lesquelles un paquet entrant est rejeté lorsque la file est pleine (mécanisme DropTail). Il appartient ainsi aux couches supérieures, situées en bordure du réseau, d’assurer les fonctionnalités manquantes. C’est ainsi que le protocole de transport TCP a été proposé afin de réaliser un transfert fiable et équitable des données. On peut également citer des applications pair-à-pair qui font transiter le trafic au sein d’un overlay géré au niveau applicatif. Cette architecture simple a permis l’émergence d’une multitude d’applications et a permis au réseau d’évoluer jusqu’à celui que nous connaissons aujourd’hui. Elle est toutefois remise en cause notamment pour son insuffisance à offrir un traitement avancé du trafic, ainsi que les garanties de service plus strictes requises par les nouvelles utilisations du réseau. Ces constatations ont motivé l’évolution des protocoles de transport, ainsi que l’introduction dans le réseau de mécanismes permettant un contrôle plus ou moins avancé du trafic.

Protocoles de transport

Les protocoles de transport utilisés majoritairement sur le réseau sont respectivement TCP (il en existe plusieurs variantes) et dans une moindre mesure UDP. TCP (Transmission Control Protocol) permet d’assurer des transferts fiables, en mode connecté, entre deux points et est ainsi généralement utilisé pour supporter les flots élastiques. TCP à notamment pour objectif le partage équitable des ressources réseau disponibles ; il existe pour cela un grand nombre d’algorithmes dont nous présenterons les principaux dans la suite. Dans une moindre mesure, on trouve aussi UDP (User Datagram Protocol) qui permet l’envoi non fiable de données entre deux entités, et fonctionne en mode non-connecté. UDP est généralement associé avec les flots streaming et n’implémente pas de mécanisme de contrôle. Notons que les flots streaming peuvent également être transportés par TCP, et que l’on trouve également des protocoles adaptatifs basés sur UDP. Lorsque des flots UDP non-adaptatifs sont en compétition avec des flots TCP, ces derniers ont tendance à adapter leur débit et être défavorisés. Bien qu’ils subissent également des pertes, les flots UDP parviennent généralement à émettre à leur débit intrinsèque.

Comportement de TCP

La prédominance du protocole TCP explique pourquoi il se retrouve au cœur de nombreuses études, et que son fonctionnement puisse guider le dimensionnement de certaines ressources du réseau, voire être l’objet de mécanismes de gestion dédiés. Bien que nous privilégions des approches agnostiques aux protocoles utilisés, il est nécessaire de présenter le fonctionnement de ce protocole afin de mieux comprendre ensuite la performance réalisée par les flots élastiques. TCP a pour but d’établir, de manière décentralisée, une allocation efficace et équitable de la bande passante disponible sur les liens traversés. Le contrôle de congestion qu’il réalise détecte les événements de congestion dans le réseau et adapte en fonction le débit d’envoi des paquets. Il a été proposé dans l’article séminal de Van Jacobson [75] afin de faire face à la saturation du réseau (congestion collapse). Cette version originale de TCP (nommée TCP Tahoe), ainsi que les améliorations de l’algorithme de contrôle de congestion qui ont suivi (Reno et NewReno) s’appuient sur la détection des pertes de paquets. Elles se produisent lorsque les connexions TCP provoquent la saturation du buffer d’un des routeurs. Une alternative utilisée par TCP Vegas [37] est d’utiliser une estimation du délai subi par les paquets lors de la traversée des différentes files d’attente. Dans la suite, sauf mention contraire, nous réfèrerons implicitement à la version TCP NewReno. Chaque paquet envoyé par TCP doit être acquitté par le récepteur. Le protocole maintient une fenêtre de congestion (cwnd), qui représente le nombre de paquets non encore acquittés, et qui permet de réguler le flux d’envoi. Le contrôle de congestion d’une connexion active (lorsque TCP est dans un mode dit congestion avoidance) repose sur l’algorithme AIMD (Additive Increase Multiplicative Decrease) qui gère l’évolution de cwnd : sa valeur est augmentée d’un pour chaque cwnd paquets acquittés, et diminuée de moitié lorsqu’une congestion est détectée. TCP possède d’autres modes de fonctionnement: slow-start intervient au début d’une connexion, afin de rapidement approcher le débit équitable ; fast recovery et fast-retransmit ont été proposées dans TCP Reno et NewReno afin de mieux gérer les événements de congestion. Padhye et al. [120] ont établi la relation entre le débit atteint par une connexion TCP en fonction du taux de perte subit.

Limites de TCP

L’allocation équitable réalisée par TCP dépend de la coopération des sources [109]. Elle est ainsi vulnérable à celles n’implémentant pas TCP, parfois dans un but malicieux  . L’algorithme AIMD, sur lequel repose l’équité, souffre également de plusieurs imperfections. Il est par exemple inefficace sur des liens possédant un produit délai x bande passante élevé, et nécessite des buffers suffisamment dimensionnés . Plusieurs propositions de protocoles “haut débit” permettent à plusieurs flots longs en compétition d’obtenir de bonnes performances, avec un certain degré d’équité. Mais comme nous le verrons dans le Chapitre 5, elles sont souvent plus agressives et ne permettent pas une coexistence équitable avec les connexions TCP Reno, ce qui est une propriété recherchée (on parle de protocoles TCP friendly). Le contrôle de cwnd en fonction des pertes subies par les connexions est également la cause d’autres imperfections de TCP. D’une part, il ne s’agit que d’une vision limitée des capacités du réseau, uniquement aux instants de congestion (action corrective). D’autre part, une perte de paquet ne signale pas nécessairement une congestion. Les réseaux optiques possèdent par exemple un taux d’erreur qui génèrera des pertes, et la réduction de cwnd et donc de débit ainsi causée ne sera compensée que tardivement, à cause de la lenteur de AIMD sur un lien à fort débit. Enfin, lors des événements de saturation, de nombreuses connexions TCP réduisent leur cwnd en même temps, ce qui entraîne une moins bonne utilisation des ressources du lien. Nous remarquons également que les débits d’accès des utilisateurs sont aujourd’hui encore relativement faibles par rapport aux capacités de cœur de réseau. Ainsi le goulot d’étranglement se situe généralement dans le réseau d’accès, et les mécanismes de TCP n’interviennent pas dans le cœur de réseau qui reste transparent, sauf pour quelques flots bien particuliers. Toutefois, l’augmentation des débits d’accès avec l’arrivée de la fibre optique pourrait déplacer ce problème plus en amont.

Vers un déploiement d’architectures de qualité de service ? 

La présence de nouvelles applications du réseau, comme la téléphonie ou la vidéo, requiert d’importantes garanties de service pour lesquelles le modèle Best Effort actuel, reposant majoritairement sur TCP, semble insuffisant. Un certain nombre de propositions mettant en œuvre de tels mécanismes ont été proposées afin d’apporter des garanties de service dans le réseau. Pourtant, les opérateurs sont toujours hésitants à introduire des mécanismes de gestion de trafic plus avancés. Le manque de preuves concernant l’efficacité de telles solutions, auquel s’ajoute leur complexité de mise-en-œuvre en est souvent la cause. Au lieu de cela, les opérateurs appliquent un surdimensionnement systématique des ressources afin de garantir une performance raisonnable lorsque le réseau n’est pas fortement chargé. Un dimensionnement qui assure une charge des liens inférieure à 40% est par exemple appliqué, pour faire face à une éventuelle augmentation de la charge en cas de panne et re-routage du trafic sur un autre lien .

Une telle gestion requiert des opérateurs des investissements réguliers coûteux, et semble être de plus en plus remise en cause avec la montée des applications gourmandes en ressources, comme la vidéo ou le pair-à-pair. On voit ainsi de nombreux réseaux déployer des mécanismes complexes d’inspection de trafic et de bridage ad-hoc. L’augmentation des capacités dans les réseaux d’accès (fibre optique, etc.) pourrait également être une motivation suffisante pour reconsidérer le déploiement de mécanismes de gestion de trafic. D’autant que certains mécanismes peuvent, comme nous le verrons, apporter une performance prévisible, présentant un avantage compétitif pour un opérateur et lui simplifiant sa tâche de dimensionnement.