1. Introduction

Nous décrivons d'abord le mécanisme par lequel TCP utilise la perte de paquets comme indication de congestion. Ensuite, nous expliquons comment, en ajoutant la gestion active de file d'attente (Active Queue Management, AQM, par exemple RED) à l'infrastructure Internet, les routeurs peuvent détecter la congestion avant que les files d'attente ne débordent, de sorte que les routeurs ne sont plus limités à utiliser la perte de paquets comme indication de congestion. Les routeurs peuvent au contraire définir le codepoint Congestion Experienced (Congestion Expérimentée, CE) dans l'en-tête IP des paquets provenant de protocoles de transport compatibles ECN. Nous décrivons quand le codepoint CE est défini dans les routeurs et décrivons les modifications nécessaires pour rendre TCP compatible ECN. Les modifications pour d'autres protocoles de transport (par exemple, unicast ou multicast non fiable, multicast fiable, autres protocoles de transport unicast fiables) peuvent être envisagées lorsque ces protocoles sont développés et passent par le processus de normalisation. Nous décrivons également dans ce document les problèmes liés à l'utilisation d'ECN dans les tunnels IP, en particulier dans les tunnels IPsec.

Un principe directeur de ce document est que, dans la mesure du possible, les mécanismes spécifiés ici devraient être déployables de manière incrémentale. Un défi pour le principe de déploiement incrémental est que certains tunnels IP préexistants sont incompatibles avec l'utilisation d'ECN. Au fur et à mesure du déploiement d'ECN, les tunnels IP incompatibles devront être mis à niveau pour se conformer aux spécifications de ce document.

Ce document rend obsolète le RFC 2481 "A Proposal to add Explicit Congestion Notification (ECN) to IP", qui définissait ECN comme un protocole expérimental (Experimental Protocol) pour la communauté Internet. Ce document met également à jour le RFC 2474 "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" concernant la définition du champ ECN dans l'en-tête IP, met à jour le RFC 2401 "Security Architecture for the Internet Protocol" pour modifier le traitement de l'octet TOS IPv4 et de l'octet de classe de trafic IPv6 dans la construction d'en-tête en mode tunnel pour être compatible avec l'utilisation d'ECN, et met à jour le RFC 793 "Transmission Control Protocol" concernant la définition de deux nouveaux drapeaux dans l'en-tête TCP.

Les algorithmes de contrôle et d'évitement de congestion de TCP sont basés sur le concept de traiter le réseau comme une boîte noire (black-box) [Jacobson88, Jacobson90]. La congestion ou tout autre état du réseau est déterminé par les systèmes terminaux en sondant l'état du réseau, c'est-à-dire en augmentant progressivement la charge sur le réseau (en augmentant la fenêtre de paquets en cours dans le réseau) jusqu'à ce que le réseau devienne congestionné et perde des paquets. Traiter le réseau comme une "boîte noire" et considérer la perte comme une indication de congestion du réseau est approprié pour les données au mieux (best-effort) pures transportées par TCP, qui sont peu ou pas du tout sensibles à la latence ou à la perte de paquets individuels. De plus, les algorithmes de gestion de la congestion de TCP intègrent certaines techniques (comme Fast Retransmit et Fast Recovery) pour minimiser l'impact de la perte du point de vue du débit. Cependant, ces mécanismes ne sont pas conçus pour aider les applications qui sont effectivement sensibles à la latence ou à la perte d'un ou plusieurs paquets individuels. Le trafic interactif (comme telnet, la navigation Web et la transmission de données audio et vidéo) peut être sensible à la perte de paquets (en particulier lors de l'utilisation d'un protocole de transmission de données non fiable tel qu'UDP), ou sensible à l'augmentation de la latence des paquets résultant de la nécessité de retransmettre les paquets après une perte (sous la sémantique de transmission de données fiable fournie par TCP).

Étant donné que TCP détermine la fenêtre de congestion appropriée en augmentant progressivement la taille de la fenêtre jusqu'à ce qu'il rencontre un paquet perdu, cela entraîne une accumulation de files d'attente au niveau du routeur goulot d'étranglement. Pour la plupart des politiques de perte de paquets des routeurs qui ne sont pas sensibles à la charge imposée par chaque flux individuel (par exemple, tail-drop (abandon en fin de file) lors du débordement de file d'attente), cela signifie que des paquets de certains flux sensibles à la latence peuvent être perdus. De plus, ces politiques d'abandon entraînent une synchronisation de perte entre plusieurs flux.

Les mécanismes de gestion active de file d'attente détectent la congestion avant que les files d'attente ne débordent et fournissent une indication de cette congestion aux nœuds terminaux. Par conséquent, la gestion active de file d'attente peut réduire le délai de mise en file d'attente inutile pour tout le trafic partageant cette file d'attente. Les avantages de la gestion active de file d'attente sont discutés dans le RFC 2309 [RFC2309]. La gestion active de file d'attente évite certaines des caractéristiques indésirables de l'abandon lors du débordement de file d'attente, y compris la synchronisation de perte indésirable entre plusieurs flux. Plus important encore, la gestion active de file d'attente signifie que les protocoles de transport avec des mécanismes de contrôle de congestion (par exemple TCP) n'ont pas à s'appuyer uniquement sur le débordement de tampon comme seule indication de congestion.

Les mécanismes de gestion active de file d'attente peuvent utiliser l'une de plusieurs méthodes pour indiquer la congestion aux nœuds terminaux. Une approche consiste à utiliser l'abandon de paquets, qui est la pratique actuelle. Cependant, la gestion active de file d'attente permet aux routeurs de séparer la politique de mise en file d'attente ou d'abandon de paquets de la politique d'indication de congestion. Par conséquent, la gestion active de file d'attente permet aux routeurs d'utiliser le codepoint Congestion Experienced (Congestion Expérimentée, CE) dans l'en-tête de paquet comme indication de congestion, plutôt que de s'appuyer uniquement sur l'abandon de paquets. Cela a le potentiel de réduire l'impact de la perte sur les flux sensibles à la latence.

Il existe certains middleboxes dans Internet (tels que pare-feu, équilibreurs de charge ou systèmes de détection d'intrusion) qui abandonnent les paquets TCP SYN configurés pour négocier ECN, ou répondent avec un RST. Ce document spécifie des procédures que les implémentations TCP peuvent utiliser pour fournir une connectivité robuste en présence de tels dispositifs.