5. Notification Explicite de Congestion dans IP (Explicit Congestion Notification in IP)
Ce document spécifie qu'Internet fournit une indication de congestion pour la congestion naissante (incipient congestion) (comme dans RED et travaux antérieurs [RJ90]), où la notification peut parfois être effectuée en marquant des paquets plutôt qu'en les abandonnant. Cela utilise le champ ECN dans l'en-tête IP, qui contient deux bits, formant quatre codepoints ECN, de '00' à '11'. Les codepoints ECN-Capable Transport (Transport Capable ECN, ECT) '10' et '01' sont définis par l'expéditeur de données pour indiquer que les points de terminaison du protocole de transport prennent en charge ECN ; nous les appelons respectivement ECT(0) et ECT(1). La phrase "the ECT codepoint" (le codepoint ECT) dans ce document fait référence à l'un ou l'autre des deux codepoints ECT. Les routeurs traitent les codepoints ECT(0) et ECT(1) comme équivalents. Les expéditeurs sont libres d'utiliser soit le codepoint ECT(0) soit ECT(1) pour indiquer ECT, sur une base paquet par paquet (packet-by-packet).
La principale motivation pour utiliser les deux codepoints ECT, ECT(0) et ECT(1), est le désir de permettre aux expéditeurs de données de vérifier que les éléments de réseau n'effacent pas le codepoint CE et que les récepteurs de données signalent correctement à l'expéditeur la réception de paquets avec le codepoint CE défini, comme requis par le protocole de transport. Les directives sur la façon dont les expéditeurs et récepteurs distinguent les codepoints ECT(0) et ECT(1) seront spécifiées dans des documents séparés pour chaque protocole de transport. En particulier, ce document ne traite pas des mécanismes permettant aux nœuds terminaux TCP de distinguer les codepoints ECT(0) et ECT(1). Les protocoles et expéditeurs qui nécessitent un seul codepoint ECT devraient utiliser ECT(0).
Le codepoint not-ECT '00' indique un paquet qui n'utilise pas ECN. Le codepoint CE '11' est défini par un routeur pour indiquer la congestion aux nœuds terminaux. Les paquets arrivant à une file d'attente pleine sont abandonnés par les routeurs, comme ce serait le cas en l'absence d'ECN.
+-----+-----+
| ECN FIELD |
+-----+-----+
ECT CE [Obsolete] Noms RFC 2481 pour les bits ECN.
0 0 Not-ECT
0 1 ECT(1)
1 0 ECT(0)
1 1 CE
Figure 1 : Champ ECN dans IP
L'utilisation de deux codepoints ECT fournit essentiellement un nonce ECN d'un bit dans l'en-tête de paquet, et lorsque les routeurs définissent le codepoint CE, ils "effacent" nécessairement le nonce [SCWA99]. Par exemple, un routeur effaçant le codepoint CE aurait une difficulté supplémentaire à reconstruire le nonce original, rendant ainsi plus probable que l'effacement répété du codepoint CE soit détecté par les nœuds terminaux. Le nonce ECN traite également le comportement incorrect des récepteurs de transport qui mentent aux expéditeurs de transport sur la définition ou non du codepoint CE dans les paquets. La motivation pour l'utilisation de deux codepoints ECT est discutée plus en détail dans la section 20, ainsi que certaines possibilités alternatives pour un quatrième codepoint ECT (c'est-à-dire le codepoint '01'). La compatibilité ascendante avec les implémentations ECN antérieures qui ne comprennent pas le codepoint ECT(1) est discutée dans la section 11.
Dans le RFC 2481 [RFC2481], le champ ECN était divisé en un bit ECN-Capable Transport (ECT) et un bit CE. Le champ ECN du RFC 2481 avec seulement le bit ECN-Capable Transport (ECT) défini correspond au codepoint ECT(0) dans ce document, et le champ ECN du RFC 2481 avec à la fois les bits ECT et CE définis correspond au codepoint CE dans ce document. Le codepoint '01' n'était pas défini dans le RFC 2481, c'est pourquoi ECT(0) est recommandé lorsqu'un seul codepoint ECT est nécessaire.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DS FIELD, DSCP | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+
DSCP: differentiated services codepoint
ECN: Explicit Congestion Notification
Figure 2 : Champs Differentiated Services et ECN dans IP
Les bits 6 et 7 de l'octet TOS IPv4 sont désignés comme le champ ECN. L'octet TOS IPv4 correspond à l'octet Traffic Class dans IPv6, et la définition du champ ECN est la même dans les deux cas. La définition de l'octet TOS IPv4 [RFC791] et de l'octet Traffic Class IPv6 a été remplacée par le champ DS (Differentiated Services, Services Différenciés) de six bits [RFC2474, RFC2780]. Les bits 6 et 7 ont été répertoriés comme Currently Unused (Actuellement Non Utilisés) dans [RFC2474] et ont été désignés dans le RFC 2780 comme approuvés pour une utilisation expérimentale pour ECN. La section 22 donne un bref historique de l'octet TOS.
En raison de l'historique instable de l'octet TOS, l'utilisation du champ ECN spécifiée dans ce document ne peut pas être garantie comme étant rétrocompatible avec les utilisations antérieures de ces deux bits avant ECN. Les dangers potentiels de ce manque de compatibilité ascendante sont discutés dans la section 22.
Après qu'un transport compatible ECN reçoive un seul paquet CE, l'algorithme de contrôle de congestion suivi par les systèmes terminaux DOIT être essentiellement le même que la réponse de contrôle de congestion à un seul paquet perdu. Par exemple, pour TCP compatible ECN, le TCP source DOIT réduire de moitié sa fenêtre de congestion pour toute fenêtre de données contenant soit une perte de paquet, soit une indication ECN.
Une raison pour exiger que la réponse de contrôle de congestion à un paquet CE soit essentiellement la même que la réponse à un paquet perdu est de s'adapter au déploiement incrémental d'ECN dans les systèmes terminaux et les routeurs. Certains routeurs peuvent abandonner des paquets compatibles ECN (en utilisant, par exemple, la même politique AQM pour la détection de congestion) tandis que d'autres routeurs définissent le codepoint CE à des niveaux de congestion équivalents. De même, les routeurs peuvent abandonner des paquets non compatibles ECN mais définir le codepoint CE sur des paquets compatibles ECN à des niveaux de congestion équivalents. Cela pourrait entraîner un traitement inéquitable des différents flux si la réponse de contrôle de congestion au codepoint CE différait de la réponse à la perte de paquets.
Un autre objectif est que les systèmes terminaux devraient réagir au plus une fois à la congestion pour chaque fenêtre de données (c'est-à-dire, au plus une fois par temps d'aller-retour), pour éviter de réagir plusieurs fois à plusieurs indications de congestion dans un seul temps d'aller-retour.
Pour les routeurs, le codepoint CE d'un paquet compatible ECN DEVRAIT SEULEMENT être défini si le routeur aurait autrement abandonné le paquet comme indication de congestion aux nœuds terminaux. Lorsque les tampons du routeur ne sont pas encore pleins et que le routeur est prêt à abandonner un paquet pour notifier aux nœuds terminaux une congestion naissante, le routeur DEVRAIT d'abord vérifier si le codepoint ECT est défini dans l'en-tête IP de ce paquet. S'il est défini, alors le routeur PEUT à la place définir le codepoint CE dans l'en-tête IP plutôt que d'abandonner le paquet.
Un environnement où tous les nœuds terminaux prennent en charge ECN pourrait permettre le développement de nouvelles normes pour définir le codepoint CE, ainsi que de nouveaux mécanismes de contrôle de congestion pour que les nœuds terminaux réagissent aux paquets CE. Cependant, cela est un sujet de recherche et n'est donc pas discuté dans ce document.
Lorsqu'un routeur reçoit un paquet CE (c'est-à-dire un paquet avec le codepoint CE défini), le codepoint CE reste inchangé et le paquet est transmis de manière normale. Lorsqu'il y a une congestion sévère et que les files d'attente du routeur sont pleines, le routeur n'a d'autre choix que d'abandonner certains paquets lorsque de nouveaux paquets arrivent. Nous nous attendons à ce que cette perte de paquets devienne relativement rare lorsque la plupart des systèmes terminaux prennent en charge ECN et participent à TCP ou à d'autres mécanismes de contrôle de congestion compatibles. Dans des environnements compatibles ECN bien provisionnés, la perte de paquets devrait principalement se produire pendant les transitoires ou en présence de sources non coopératives.
La discussion ci-dessus sur le moment où le CE peut être défini au lieu d'abandonner un paquet s'applique par défaut à tous les comportements par saut (Per-Hop Behaviors, PHBs) des Services Différenciés (Differentiated Services) [RFC 2475]. Les spécifications de PHB peuvent fournir plus de détails sur la façon dont les implémentations conformes choisissent entre définir CE et abandonner des paquets, mais ce n'est pas obligatoire. Les routeurs NE DOIVENT ABSOLUMENT PAS définir CE au lieu d'abandonner des paquets lorsque les abandons qui se produisent sont causés par des raisons autres que la congestion ou que l'indication d'une congestion naissante aux nœuds terminaux est souhaitée (par exemple, un nœud de périphérie diffserv peut être configuré pour abandonner inconditionnellement certaines classes de trafic pour les empêcher d'entrer dans son domaine diffserv).
Nous nous attendons à ce que les routeurs définissent le codepoint CE en fonction de la congestion naissante telle qu'indiquée par la taille moyenne de la file d'attente, en utilisant l'algorithme RED recommandé dans [FJ93, RFC2309]. À notre connaissance, c'est la seule proposition actuellement discutée dans l'IETF pour que les routeurs abandonnent activement des paquets avant le débordement de tampon. Cependant, ce document ne tente pas de prescrire un mécanisme particulier de gestion active de file d'attente, laissant ce travail, si nécessaire, à d'autres domaines de l'IETF. Bien qu'ECN soit étroitement lié à la nécessité d'un mécanisme de gestion active de file d'attente raisonnable au niveau des routeurs, l'inverse n'est pas vrai ; le développement et le déploiement de mécanismes de gestion active de file d'attente sont indépendants d'ECN, utilisant la perte de paquets comme indication de congestion en l'absence d'ECN dans l'architecture IP.