Garanties de service pour les flots IP 

Ce chapitre passe en revue un ensemble de mécanismes de gestion du trafic, ainsi que les principales architectures de garantie de service proposées dans la littérature. Nous posons les bases nécessaire à l’analyse des différentes propositions au vu de notre compréhension du trafic, de sa performance et du challenge que représente l’introduction de nouveaux mécanismes dans un réseau opérationnel. Une discussion des avantages et des faiblesses de chaque solution nous permet de positionner et de justifier l’approche alternative Flow-Aware Networking (FAN), qui sera détaillée dans le prochain chapitre. Il appartient ainsi aux couches supérieures, situées en bordure du réseau, d’assurer les fonctionnali- té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.

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. 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 per- met 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 Multiplica- tive 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 est par exemple inefficace sur des liens possédant un produit délai x bande passante élevé, et néces- site des buffers suffisamment dimensionnés (cette problématique sera abordée plus en détails dans le Chapitre 4). 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, unique- ment 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.