Proposition d’ajout de la notification explicite d’encombrement (ECN) à IP

Statut de ce mémoire

Le présent mémoire définit un protocole expérimental pour la communauté de l’Internet. Il ne spécifie en aucun cas une norme de l’Internet. Il invite à des discussions et suggestions pour son amélioration. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction

Copyright (C) The Internet Society (1999). Tous droits réservés.

Résumé

Cette note décrit une proposition d’ajout de la notification explicite d’encombrement (ECN, Explicit Congestion Notification) à IP. TCP est actuellement le protocole de transport dominant utilisé dans l’Internet. On commence par décrire l’utilisation par TCP des abandons de paquet comme indication d’encombrement. On explique ensuite qu’avec l’ajout de la gestion active de file d’attente (par exemple, RED) à l’infrastructure de l’Internet, grâce à laquelle les routeurs détectent l’encombrement avant le débordement de la file d’attente, les routeurs ne sont plus limités à l’abandon de paquets comme indication d’encombrement. Les routeurs peuvent à la place établir un bit Encombrement rencontré (CE, Congestion Experienced) dans l’en-tête de paquet à partir des protocoles de transport à capacité ECN. On décrit ensuite quand le bit CE doit être mis dans les routeurs, et on décrit les modifications à TCP qui seront nécessaires pour lui donner la capacité ECN. Les modifications des autres protocoles de transport (par exemple, les protocoles de transport non fiables d’envoi individuel ou de diffusion groupée, de diffusion groupée fiable, ou d’autres protocoles de transport fiable en envoi individuel) pourraient être considérés lorsque ces protocoles seront développés et avanceront dans le processus de normalisation.

1.   Conventions rédactionnelles

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF", lorsque ils apparaissent dans le présent document, sont à interpréter comme décrit dans la [RFC2119].

2.   Introduction

Les algorithmes de contrôle et d'évitement d'encombrement de TCP sont fondés sur la notion que le réseau est une boîte noire [Jacobson88], [Jacobson90]. L'état d'encombrement ou autre du réseau est déterminé par la vérification par le système d'extrémité de l'état du réseau, en augmentant graduellement la charge du réseau (en augmentant la fenêtre de paquets qui sont en cours dans le réseau jusqu'à ce que le réseau devienne encombré et qu'un paquet soit perdu). Traiter le réseau comme une "boîte noire" et traiter la perte comme une indication d'encombrement dans le réseau est approprié pour les données portées comme "au mieux" pures par TCP qui a peu ou pas de sensibilité au délai ou à la perte de paquets individuels. De plus, les algorithmes de gestion de l'encombrement de TCP ont des techniques incorporées (telles que la retransmission rapide et la récupération rapide) pour minimiser l'impact des pertes dans une perspective de débit.

Cependant, ces mécanismes ne sont pas destinés à aider les applications qui sont en fait sensibles au délai ou à la perte d'un ou plusieurs paquets individuels. Le trafic interactif tel que Telnet, la navigation sur la Toile et le transfert de données audio et vidéo peut être sensible aux pertes de paquet (en utilisant un transport non fiable pour la livraison des données tel que UDP) ou l'augmentation de la latence des paquets causée par le besoin de retransmettre le paquet après une perte (pour la livraison fiable des données comme dans TCP).

Comme TCP détermine la fenêtre d'encombrement appropriée à utiliser en augmentant graduellement la taille de fenêtre jusqu'à rencontrer un abandon de paquet, cela cause la construction de files d'attente au routeur qui fait le goulet d'étranglement. Comme la plupart des politiques d'abandon de paquet chez les routeurs ne sont pas sensibles à la charge portée par chaque flux individuel, cela signifie que certains des paquets de flux sensibles à la latence vont être abandonnés. Les mécanismes de gestion active de file d'attente détectent l'encombrement avant le débordement de la file d'attente, et donnent une indication de cet encombrement aux nœuds d'extrémité. Les avantages de la gestion active de file d'attente sont exposés dans la [RFC2309]. La gestion active de file d'attente évite certaines des mauvaises propriétés de l'abandon lors du débordement de file d'attente, y compris l'indésirable synchronisation des pertes sur des flux multiples. Plus important, la gestion active de file d'attente signifie que les protocoles de transport avec contrôle de l'encombrement (par exemple, TCP) n'ont pas à s'appuyer sur le débordement de mémoire tampon comme seule indication d'encombrement. Cela peut réduire le délai inutile de mise en file d'attente pour tout le trafic qui partage cette file d'attente.

Les mécanismes de gestion active de file d'attente peuvent utiliser une des nombreuses méthodes d'indication d'encombrement aux nœuds d'extrémité. Une d'elles est l'utilisation de l'abandon de paquet, comme c'est fait actuellement. Cependant, la gestion active de file d'attente permet au routeur de distinguer les politiques de mise en file d'attente ou d'abandon de paquets des politiques qui indiquent l'encombrement. Donc, la gestion active de file d'attente permet aux routeurs d'utiliser le bit Encombrement rencontré (CE, Congestion Experienced) dans un en-tête de paquet comme indication d'encombrement, au lieu de s'appuyer seulement sur les abandons de paquet.

3.   Hypothèses et principes généraux

Cette section décrit certains des plus importants principes et hypothèses de conception qui ont guidé les choix de cette proposition.

(1)   L’encombrement peut persister sur des échelles temporelles différentes. Ces échelles qui nouc concernent sont les événements d’encombrement qui peuvent durer plus longtemps qu’un délai d’aller-retour.

(2)   Le nombre de paquets dans un flux individuel (par exemple, une connexion TCP ou un échange utilisant UDP) peut aller d’un petit nombre de paquets à un assez grand nombre. On s’intéresse à la gestion d’encombrement causé par des flux qui envoient assez de paquets oiur qu’ils soient encore actifs lorsque le retour du réseau les atteint.

(3)   Les nouveaux mécanismes pour le contrôle et l’évitement d’encombrement doivent coexister et coopérer avec les mécanismes existants de contrôle d’encombrement. En particulier, les nouveaux mécanismes doivent coexisteer avec les méthodes actuelles de TCP pour s’adapter à l’encombrement et avec la pratique actuelle des routeurs d’abandonner les paquets dans les périodes d’encombrement.

(4)   Parce qu’ECN sera vraisemblablement adopté graduellement, il est essentiel de s’accommoder de la migration. Certains routeurs pourront encore seulement abandonner des paquets pour indiquer l’encombrement, et certains systèmes d’extrémité pourront n’avoir pas la capacité ECN. La stratégie la plus viable est celle qui s’accommode d’un déploiement incrémentaire sans avoir recours à des "îles" à capacité ECN et à des environnements qui en sont dépourvus.

(5)   L’acheminement asymétrique sera vraisemblablement le régime normale dans l’Internet. Le chemin (séquence de liaisons et de routeurs) suivi par les paquets de données peut être différent du chemin suivi par les paquets d’accusé de réception dans la direction inverse.

(6)   De nombreux routeurs traitent les en-têtes "réguliers" dans less paquets IP plus efficacement qu’ils ne traitent les informations d’en-tête dans les options IP. Cela suggère de conserver les informations sur l’encombrement rencontré dans les en-têtes réguliers d’un paquet IP.

(7)   On doit reconnaître que tous les systèmes d’extrémité ne vont pas coopérer aux mécanismes de contrôle de l’encombrement. Cependant, les nouveaux mécanismes ne devraient pas rendre plus facile aux applications TCP de désactiver le contrôle d’encombrement TCP. Le bénéfice d’un mensonge sur la participation aux nouveaux mécanismes tels que la capacité ECN devrait être faible.

4.   Détection précoce aléatoire

La détection précoce aléatoire (RED, Random Early Detection) est un mécanisme pour la gestion active de file d’attente qui a été proposé pour détecter l’encombrement naissant [FJ93], et est actuellement déployé dans le cœur de réseau de l’Internet [RFC2309]. Bien que RED soit destiné à être un mécanisme général utilisant une des multiples alternatives d’indication d’encombrement, dans l’environnement actuel de l’Internet, RED se restreint à utiliser l’abandon de paquet comme mécanisme d’indication d’encombrement. RED abandonne les paquets sur la base de la longueur moyenne de file d’attente au-delà d’un seuil, plutôt que seulement du débordement de la file d’attente. Cependant, lorsque RED abandonne des paquets avant que la file d’attente ne déborde réellement, RED n’est pas forcé à éliminer le paquet par des limitations de mémoire.

RED pourrait établir un bit Encombrement rencontré (CE, Congestion Experienced) dans l’en-tête de paquet au lieu d’abandonner le paquet, si un tel bit était fourni dans l’en-tête IP et compris par le protocole de transport. L’utilisation du bit CE permettrait au ou aux receveurs de recevoir le paquet, évitant des retards potentiels excessifs dus aux retransmissions après les pertes de paquet. On utilise le terme de "paquet CE" pour noter un paquet qui a le bit CE établi.

5.   Notification explicite d'encombrement dans IP

Nous proposons que l’Internet fournisse une indication d’encombrement pour l’encombrement naissant (comme dans RED et dans un travail antérieur [RJ90]) où la notification peut parfois se faire par le marquage des paquets plutôt que par leur abandon. Cela exigerait un champ ECN de deux bits dans l’en-tête IP. Le bit de transport à capacité ECN (ECT, ECN-Capable Transport) serait établi par l’envoyeur des données pour indiquer que les points d’extrémité du protocole de transport sont à capacité ECN. Le bit CE serait établi par le routeur pour indiquer l’encombrement aux nœuds d’extrémité. Les routeurs qui ont un paquet qui arrive sur une file d’attente pleine abandonneraient le paquet, tout comme ils le font maintenant.

Les bits 6 et 7 dans l’octet TOS IPv4 sont désignés comme le champ ECN. Le bit 6 est désigné comme bit ECT, et le bit 7 est désigné comme le bit CE. L’octet TOS d’IPv4 correspond à l’octet Classe de trafic dans IPv6. Les définitions pour l’octet TOS IPv4 [RFC791] et l’octet Classe de trafic IPv6 sont destinées à être supplantées par le champ DS (Services différenciés) [RFC2474]. Les bits 6 et 7 sont mentionnés dans la [RFC2474] comme actuellement inutilisés. La Section 19 donne un bref historique de l’octet TOS. À cause de l’histoire instable de l’octet TOS, l’utilisation du champ ECN telle que spécifiée dans le présent document ne peut pas être garantie comme rétro compatible avec toutes les utilisations passées de ces ceux bits. Les dangers potentiels de ce manque de rétro compatibilité sont exposés à la Section 19.

À réception par un transport à capacité ECN d’un seul paquet CE, les algorithmes de contrôle d’encombrement suivis par les systèmes d’extrémité DOIVENT être essentiellement les mêmes que la réponse de contrôle d’encombrement à un *seul* paquet abandonné. Par exemple, pour TCP à capacité ECN, le TCP de source est obligé de diminuer par deux sa fenêtre d’encombrement pour toute fenêtre de données contenant soit un abandon de paquet, soit une indication ECN. Cependant, on doit souligner des exceptions notables à la réaction du TCP source, en rapport avec les détails à plus court terme suivants de mises en œuvre particulières de TCP. Pour les réponses de TCP à une indication ECN, on ne recommande pas un tel comportement au démarrage lent de TCP Tahoe en réponse à un abandon de paquet, ou à l’attente de TCP Reno d’environ un demi délai d’aller-retour durant une récupération rapide.

Une raison de l’exigence que la réponse de contrôle d’encombrement au paquet CE soit essentiellement la même que la réponse à un abandon de paquet est de s’accommoder du déploiement incrémentaire de ECN à la fois dans les systèmes d’extrémité et dans les routeurs. Certains routeurs peuvent abandonner les paquets à capacité ECN (par exemple, en utilisant les mêmes politiques que RED pour la détection d’encombrement) alors que d’autres routeurs établissent le bit CE, pour des niveaux équivalents d’encombrement. De même, un routeur pourrait abandonner un paquet sans capacité ECN mais établir le bit CE dans un paquet à capacité ECN, pour des niveaux d’encombrement équivalents. Des réponses de contrôle d’encombrement différentes à une indication de bit CE et à un abandon de paquet pourraient résulter en un traitement injuste des différents flux.

Une exigence supplémentaire est que les systèmes d’extrémité devraient réagir à l’encombrement au plus une fois par fenêtre de données (c’est-à-dire, au plus une fois par délai d’aller-retour) pour éviter de réagir plusieurs fois à plusieurs indications d’encombrement au sein d’un aller-retour.

Pour un routeur, le bit CE d’un paquet à capacité ECN ne devrait être établi que si le router aurait autrement abandonné le paquet comme indication d’encombrement aux nœuds d’extrémité. Lorsque la mémoire tampon du routeur n’est pas encore pleine et que le routeur est prêt à abandonner un paquet pour informer les nœuds d’extrémité d’un encombrement naissant, le routeur devrait d’abord vérifier pour voir si le bit ECT est mis dans l’en-tête IP de ce paquet. Si il l’est, au lieu d’abandonner le paquet, le routeur PEUT à la place établir le bit CE dans l’en-tête IP.

Un environnement dans lequel tous les nœuds d’extrémité sont à capacité ECN pourrait permettre que soient développés de nouveaux critères pour établir le bit CE, et de nouveaux mécanismes de contrôle d’encombrement pour la réaction des nœuds d’extrémité aux paquets CE. Cependant, ceci fait encore l’objet de recherches et n’est pas en tant que tel traité dans le présent document.

Lorsque un paquet CE est reçu par un routeur, le bit CE est laissé inchangé, et le paquet transmis comme d’habitude. Lorsque un encombrement sévère s’est produit et que la file d’attente du routeur est pleine, le routeur n’a alors pas le choix et doit abandonner des paquets lorsqu’il en arrive un nouveau. On prévoit que de telles pertes de paquet vont devenir relativement peu fréquentes lorsque une majorité de systèmes d’extrémité seront devenus à capacité ECN et participeront au mécanisme TCP de contrôle d’encombrement ou à un autre mécanisme compatible. Dans un réseau provisionné de façon adéquate dans un tel environnement à capacité ECN, les pertes de paquets devraient principalement survenir durant des périodes transitoires ou en présence de sources non coopératives.

On prévoit que les routeurs établiront le bit CE en réponse à un encombrement naissant comme indiqué par la taille moyenne de file d’attente, en utilisant les algorithmes RED suggérés dans [FJ93], [RFC2309]. À notre connaissance, c’est la seule proposition actuellement en discussion dans l’IETF pour un abandon proactif par les routeurs, avant le débordement de la mémoire tampon. Cependant, le présent document ne cherche pas à spécifier un mécanisme particulier pour la gestion active de file d’attente, laissant cette tâche, si nécessaire, aux autres domaines de l’IETF. Bien que ECN soit inextricablement lié à la gestion active de file d’attente au routeur, l’inverse ne tient pas ; les mécanismes de gestion active de file d’attente ont été développés et déployés indépendamment de ECN, en utilisant les abandons de paquet comme indications d’encombrement en l’absence de ECN dans l’architecture IP.

6.   Prise en charge du protocole de transport

ECN requiert la prise en charge par un autre protocole de transport, en plus de la fonctionnalité donnée par le champ ECN dans l’en-tête de paquet IP. Le protocole de transport pourrait exiger une négociation entre les points d’extrémité durant l’établissement pour déterminer si tous les points d’extrémité sont à capacité ECN, afin que l’envoyeur puisse établir le bit ECT dans les paquets transmis. Ensuite, le protocole de transport doit être capable de réagir de façon appropriée à la réception de paquets CE. Cette réaction pourrait être sous la forme d’une information par le receveur des données à l’envoyeur des données du paquet CE reçu (par exemple, TCP), du désabonnement d’un groupe de diffusion groupée en couche par le receveur des données (par exemple, RLM [MJV96]), ou de quelque autre action qui réduise finalement le taux d’arrivée de ce flux chez ce receveur.

Le présent document ne traite que de l’ajout de la capacité ECN à TCP, laissant les questions des rapports de ECN avec les autres protocoles de transport à de futures recherches. Pour TCP, ECN exige trois nouveaux mécanismes : la négociation entre les points d’extrémité durant l’établissement pour déterminer si ils sont tous deux à capacité ECN ; un fanion ECN-Echo dans l’en-tête TCP afin que le receveur des données puisse informer l’envoyeur des données lorsque un paquet CE a été reçu, et un fanion Fenêtre d’encombrement réduite (CWR, Congestion Window Reduced) dans l’en-tête TCP pour que l’envoyeur des données puisse informer le receveur de la réduction de la fenêtre d’encombrement. La prise en charge exigée des autres protocoles de transport sera vraisemblablement différente, en particulier pour les protocoles de transport fiable ou non fiables de diffusion groupée, et devra être déterminée lorsque d’autres protocoles de transport seront proposés à la normalisation par l’IETF.

6.1   TCP

Les paragraphes suivants décrivent en détail l’utilisation proposée de ECN dans TCP. Cette proposition est décrite dans une forme essentiellement semblable à celle de [Floyd94]. On suppose que le TCP source utilise les algorithmes de contrôle d’encombrement standard de démarrage lent (Slow-start), de retransmission rapide (Fast Retransmit) et de récupération rapide (Fast Recovery) de la [RFC2001].

Cette proposition spécifie deux nouveaux fanions dans le champ Réservé de l’en-tête TCP. Le mécanisme TCP pour négocier la capacité ECN utilise le fanion ECN-Echo dans l’en-tête TCP. (Il était appelé fanion Notifie ECN dans des documentsn antérieurs.) Le bit 9 dans le champ Réservé de l’en-tête TCP est appelé fanion ECN-Echo. La localisation du champ Réservé de 6 bits dans l’en-tête TCP est montrée à la Figure 3 de la [RFC793].

Pour permettre au receveur TCP de déterminer quand cesser d’établir le fanion ECN-Echo, nous introduisons un deuxième nouveau fanion dans l’en-tête TCP, le fanion Fenêtre d’encombrement réduite (CWR, Congestion Window Reduced). Le fanion CWR est alloué au bit 8 dans le champ Réservé de l’en-tête TCP.

L’utilisation de ces fanions est décrite dans les paragraphes suivants.

6.1.1   Initialisation de TCP

Dans la phase d’établissement de la connexion TCP, la source et la destination TCP échangent des informations sur leur désir et/ou capacité d’utiliser ECN. Après l’achèvement de cette négociation, l’envoyeur TCP établit le bit ECT dans l’en-tête IP des paquets de données pour indiquer au réseau que le transport est capable et désireux de participer à ECN pour ce paquet. Cela va indiquer aux routeurs qu’ils peuvent marquer ce paquet avec le bit CE, si ils veulent utiliser cela comme méthode de notification d’encombrement. Si la connexion TCP ne souhaite pas utiliser la notification ECN pour un paquet particulier, l’envoyeur TCP met le bit ECT égal à 0 (c’est-à-dire, non établi) et le receveur TCP ignore le bit CE dans le paquet reçu.

Lorsque un nœud envoie un paquet TCP SYN, il peut établir les fanions ECN-Echo et CWR dans l’en-tête TCP. Pour un paquet SYN, l’établissement des deux fanions ECN-Echo et CWR est défini comme l’indication que le TCP envoyeur est à capacité ECN, plutôt que comme une indication d’encombrement ou de réponse d’encombrement. Plus précisément, un paquet SYN avec les deux fanions ECN-Echo et CWR établis indique que la mise en œuvre TCP qui transmet le paquet SYN va participer à ECN à la fois comme envoyeur et comme receveur. Comme receveur, elle va répondre aux paquets de données entrants qui ont le bit CE établi dans l’en-tête IP en établissant le fanion ECN-Echo dans les paquets d’accusé de réception (ACK, Acknowledgement) TCP. Comme envoyeur, elle va répondre aux paquets entrants qui ont le fanion ECN-Echo établi en réduisant la fenêtre d’encombrement comme approprié.

Lorsque un nœud envoie un paquet SYN-ACK, il peut établir le fanion ECN-Echo, mais il n’établit pas le fanion CWR. Pour un paquet SYN-ACK, le schéma du fanion ECN-Echo établi et du fanion CWR non établi dans l’en-tête TCP est défini comme l’indication que le TCP qui transmet le paquet SYN-ACK est à capacité ECN.

Se pose la question de savoir pourquoi nous choisissons d’avoir le TCP qui envoie le SYN établir deux fanions en rapport avec ECN dans le champ Réservé de l’en-tête TCP pour le paquet SYN, alors que le TCP qui répond en envoyant le SYN-ACK établit seulement un fanion en rapport avec ECN dans le paquet SYN-ACK. Cette asymétrie est nécessaire pour la robustesse de la négociation de la capacité ECN avec les mises en œuvre déployées de TCP. Il existe au moins une mise en œuvre de TCP dans laquelle les receveurs TCP établissent le champ Réservé de l’en-tête TCP dans les paquets ACK (et donc, le SYN-ACK) simplement pour refléter le champ Réservé de l’en-tête TCP dans le paquet de données reçu. Comme le paquet TCP SYN établit les fanions ECN-Echo et CWR pour indiquer la capacité ECN, alors que le paquet SYN-ACK établit seulement le fanion ECN-Echo, le TCP envoyeur interprète correctement le reflet d’un receveur de ses propres fanions dans le champ Réservé comme l’indication que le receveur n’a pas la capacité ECN.

6.1.2   Envoyeur TCP

Pour une connexion TCP qui utilise ECN, les paquets de données sont transmis avec le bit ECT établi dans l’en-tête IP (mis à "1"). Si l’envoyeur reçoit un paquet ACK ECN-Echo (c’est-à-dire, un paquet ACK avec le fanion ECN-Echo établi dans l’en-tête TCP), l’envoyeur sait alors que de l’encombrement a été rencontré dans le réseau sur le chemin de l’envoyeur au receveur. L’indication d’encombrement devrait être traitée comme une perte due à l’encombrement dans un TCP sans capacité ECN. C’est-à-dire que la source TCP diminue de moitié sa fenêtre d’encombrement "cwnd" et réduit le seuil de démarrage lent "ssthresh". Le TCP envoyeur N’AUGMENTE PAS la fenêtre d’encombrement en réponse à la réception d’un paquet ACK ECN-Echo.

Une condition critique est que TCP ne réagisse pas aux indications d’encombrement plus d’une fois par fenêtre de données (ou plus librement, plus d’une fois par délai d’aller-retour). C’est-à-dire que la fenêtre d’encombrement de l’envoyeur TCP ne devrait être réduite qu’une seule fois en réponse à une série de paquets abandonnés et/ou CE à partir d’une seule fenêtre de données. De plus, la source TCP ne devrait pas diminuer le seuil de démarrage lent, ssthresh, si il a été diminué durant le dernier délai d’aller-retour. Cependant, si un paquet retransmis est abandonné ou a le bit CE établi, ceci est alors interprété par le TCP source comme une nouvelle instance d’encombrement.

Après que la source TCP a réduit la fenêtre d’encombrement en réponse à un paquet CE, les accusés de réception entrants qui continuent d’arriver peuvent "périmer" les paquets sortants comme permis par la fenêtre d’encombrement réduite. Si la fenêtre d’encombrement consiste seulement en une taille maximum de segment (MSS, maximum segment size), et si le TCP envoyeur reçoit un paquet ACK ECN-Echo, le TCP envoyeur devrait en principe réduire encore sa fenêtre d’encombrement de moitié. Cependant, la valeur de la fenêtre d’encombrement a une limite inférieure de la valeur de une MSS. Si le TCP envoyeur devait continuer d’envoyer, en utilisant une fenêtre d’encombrement de une MSS, il en résulterait la transmission d’un seul paquet par délai d’aller retour. Nous pensons qu’il est souhaitable de réduire encore le taux d’envoi de l’envoyeur TCP, à réception d’un paquet ECN-Echo lorsque la fenêtre d’encombrement est de un. On utilise le temporisateur de retransmission comme moyen de réduire encore le taux dans ces circonstances. Donc, le TCP envoyeur devrait aussi rétablir le temporisateur de retransmission à réception du paquet ECN-Echo lorsque la fenêtre d’encombrement est de un. Le TCP envoyeur va alors être capable d’envoyer un nouveau paquet lorsque expirera le temporisateur de retransmission.

[Floyd94] discute de la réponse de TCP à ECN plus en détails. [Floyd98] discute de l’essai de validation dans le simulateur ns, qui illustre une large gamme de scénarios ECN. Ces scénarios incluent ce qui suit: un ECN suivi par un autre ECN, une retransmission rapide, ou une fin de temporisation de retransmission; une fin de temporisation de retransmission ou une retransmission rapide suivie d’une ECN, et une fenêtre d’encombrement d’un paquet suivie par une ECN.

TCP suit les algorithmes existants pour l’envoi de paquets de données en réponse à des accusés de réception entrants, à plusieurs accusés de réception dupliqués, ou à des fins de temporisation de retransmission [RFC2001].

6.1.3   Receveur TCP

Lorsque TCP reçoit un paquet de données CE au système d’extrémité de destination, le TCP qui reçoit les données établit le fanion ECN-Echo dans l’en-tête TCP du paquet ACK suivant. Si est mise en œuvre une rétention de ACK, comme dans les mises en œuvre courantes TCP de " ACK retardé" ou le receveur TCP peut envoyer un accusé de réception pour deux paquets de données arrivants, le fanion ECN-Echo dans le paquet ACK sera alors établi dans le fanion OR des bits CE de tous les paquets de données dont il est accusé réception. C’est-à-dire que si un des paquets de données reçus est un paquet CE, l’accusé de réception en retour a le fanion ECN-Echo établi.

Pour donner de la robustesse contre la possibilité de l’abandon d’un paquet ACK portant un fanion ECN-Echo, le receveur TCP doit établir le fanion ECN-Echo dans une série de paquets ACK. Le receveur TCP utilise le fanion CWR pour déterminer quand arrêter d’établir le fanion ECN-Echo.

Lorsque un TCP à capacité ECN réduit sa fenêtre d’encombrement pour une raison quelconque (à cause de la fin d’un temporisateur de retransmission, d’une retransmission rapide, ou en réponse à une Notification ECN), le TCP établit le fanion CWR dans l’en-tête TCP du premier paquet de données envoyé après la réduction de la fenêtre. Si ce paquet de données est abandonné dans le réseau, l’envoyeur TCP devra alors réduire encore la fenêtre d’encombrement et retransmettre le paquet abandonné. Donc, le message Fenêtre d’encombrement réduite est livré de façon fiable au receveur des données.

Après qu’un receveur TCP a envoyé un paquet ACK avec le bit ECN-Echo établi, ce receveur TCP continue d’établir le fanion ECN-Echo dans les paquets ACK jusqu’à ce qu’il reçoive un paquet CWR (un paquet avec le fanion CWR établi). Après la réception du paquet CWR, les accusés de réception pour les paquets de données non CE suivants n’ont plus le fanion ECN-Echo établi. Si un autre paquet CE est reçu par le receveur des données, celui-ci enverra à nouveau des paquets ACK avec le fanion ECN-Echo établi. Bien que la réception d’un paquet CWR ne garantisse pas que le message ECN-Echo ait été reçu par le receveur des données, cela indique bien que l’envoyeur des données a réduit la fenêtre d’encombrement à un moment *après* l’envoi du paquet de données pour lequel le bit CE était établi.

Nous avons déjà spécifié qu’un envoyeur TCP réduit la fenêtre d’encombrement au plus une fois par fenêtre de données. Ce mécanisme exige une certaine attention pour s’assurer que l’envoyeur réduit sa fenêtre d’encombrement au plus une fois par indication ECN, et que plusieurs messages ECN sur plusieurs fenêtres successives de données sont correctement rapportées à l’envoyeur ECN. Ceci est exposé plus en détails dans [Floyd98].

6.1.4   Encombrement sur le chemin des ACK

Pour la génération actuelle des algorithmes de contrôle d’encombrement TCP, les purs paquets d’accusé de réception (par exemple, les paquets qui ne contiennent aucune donnée d’accompagnement) devraient être envoyés avec le bit ECT non établi. Les receveurs TCP actuels n’ont pas de mécanisme pour réduire le trafic sur le chemin d’accusé de réception en réponse aux notifications d’encombrement. Les mécanismes de réponse à l’encombrement sur le chemin d’accusé de réception sont des domaines pour les recherches actuelles et futures. (Une possibilité simple serait que l’envoyeur réduise sa fenêtre d’encombrement lorsque il reçoit un paquet ACK pur avec le bit CE établi). Pour les mises en œuvre de TCP actuelles, un seul ACK abandonné a généralement seulement un très petit effet sur le taux d’envoi de TCP.

7.   Résumé des changements nécessaires pour IP et TCP

Deux bits doivent être spécifiés dans l’en-tête IP, le bit Transport à capacité ECN (ECT, ECN-Capable Transport) et le bit Encombrement rencontré (CE, Congestion Experienced). Le bit ECT à "0" indique que le protocole de transport va ignorer le bit CE. C’est la valeur par défaut pour le bit ECT. Le bit ECT mis à "1" indique que le protocole de transport peut et est capable de participer à ECN.

La valeur par défaut pour le bit CE est "0". Le routeur règle le bit CE à "1" pour indiquer l’encombrement aux nœuds d’extrémité. Le bit CE dans un en-tête de paquet ne devrait jamais être remis de "1" à "0" par un routeur.

TCP exige trois changements, une phase de négociation durant l’établissement pour déterminer si les deux nœuds d’extrémité sont à capacité ECN et deux nouveaux fanions dans l’en-tête TCP, à partir des fanions "réservé" dans le champ Fanions de TCP. Le fanion ECN-Echo est utilisé par le receveur des données pour informer l’envoyeur des données d’un paquet CE reçu. Le fanion Fenêtre d’encombrement réduite est utilisé par l’envoyeur des données pour informer le receveur des données que la fenêtre d’encombrement a été réduite.

8.   Non relation avec l'indicateur EFCI d'ATM ou FECN du relais de trame

Comme les mécanismes de contrôle de l’encombrement de l’ATM et du relais de trame ont normalement été définis sans aucune notion de taille moyenne de file d’attente comme base de la détermination qu’un nœud intermédiaire est encombré, on estime qu’ils fournissent un signal très bruyant. La réaction de l’envoyeur TCP spécifiée dans ce projet pour ECN N’EST PAS la réaction appropriée pour un signal de notification d’encombrement aussi bruyant. On s’attend à ce que les mécanismes EFCI de l’ATM et FECN du relais de trame soient bientôt dépassés au sein du réseau ATM. Cependant, si les routeurs qui font l’interface avec le réseau ATM ont un moyen pour maintenir la file d’attente moyenne à l’interface et l’utiliser pour arriver à une détermination fiable de l’encombrement du sous réseau ATM, ils peuvent utiliser la notification ECN qui est définie ici.

Nous soulignons qu’un *seul* paquet avec le bit CE établi dans un paquet IP cause la réponse de la couche transport, en termes de contrôle de l’encombrement, comme le ferait un abandon de paquet. Comme tel, le bit CE n’est pas une aussi bonne correspondance pour un signal transitoire que celui qui se fonde sur la taille instantanée de la file d’attente. Cependant, des expériences de techniques à la couche 2 (par exemple, dans des commutateurs ATM ou de relais de trame) devraient être encouragées. Par exemple, en utilisant un schéma comme RED (où le marquage des paquets se fonde sur la longueur moyenne de la file d’attente excédant un seuil) les appareils de couche 2 pourraient fournir une indication d’encombrement raisonnablement fiable. Lorsque tous les appareils de couche 2 d’un chemin établissent le propre bit Encombrement rencontré de cette couche (par exemple, le bit EFCI pour ATM, le bit FECN en relais de trame) de façon fiable, le routeur d’interface pour le réseau de couche 2 pourrait alors copier l’état du bit Encombrement rencontré de cette couche 2 dans le bit CE de l’en-tête IP. On reconnaît que ce n’est pas la pratique actuelle, ni que c’est le standard actuel. Cependant, encourager les expérimentations de cette manière peut fournir les informations nécessaires pour permettre l’évolution des mécanismes de couche 2 existants pour fournir des moyens plus fiables d’indication d’encombrement, lorsque ils utilisent un seul bit pour indiquer l’encombrement.

9.   Non conformité des nœuds d'extrémité

Cette section discute des problèmes qui concernent la vulnérabilité de ECN aux nœuds non conformes (c’est-à-dire, les nœuds d’extrémité qui établissent le bit ECT dans les paquets transmis mais qui ne répondent pas aux paquets CE reçus). On avance que l’ajout de ECN à l’architecture IP n’augmenterait pas significativement la vulnérabilité actuelle de l’architecture aux flux qui ne répondent pas.

Même pour les environnements non ECN, il y a de sérieux soucis sur les dommages qui peuvent être causés par les flux non conformes ou insensibles (c’est-à-dire, les flux qui ne répondent pas aux indications de contrôle d’encombrement en réduisant leur taux d’arrivée sur la liaison encombrée). Par exemple, un nœud d’extrémité pourrait "débrancher le contrôle d’encombrement" en ne réduisant pas sa fenêtre d’encombrement en réponse à des abandons de paquet. Ceci pose un problème dans l’Internet actuel. On a avancé que les routeurs auront à déployer des mécanismes pour détecter et traiter de façon différenciée les paquets provenant de flux non conformes. Il a aussi été avancé que des techniques telles que la programmation par flux de bout en bout et l’isolation des flux les uns des autres, les services différenciés, ou la réservation de bout en bout pourraient supprimer certains des effets les plus dommageables des flux insensibles.

Il a été avancé que l’abandon de paquets en lui-même peut être une dissuasion adéquate à la non-conformité, et que l’utilisation de ECN supprime cette dissuasion. On répondra que (1) les routeurs à capacité ECN conservent le comportement d’abandon de paquet dans les moments de fort encombrement, et (2) même en période de fort encombrement, l’abandon de paquets n’est pas, par lui-même, une dissuasion adéquate pour la non conformité.

D’abord, les routeurs à capacité ECN vont seulement marquer les paquets (au lieu de les éliminer) lorsque le taux de marquage de paquet est raisonnablement faible. Durant les périodes où la taille moyenne de file d’attente dépasse un seuil supérieur, et donc que le taux potentiel de marquage de paquet serait élevé, nous recommandons que les routeurs abandonnent les paquets plutôt que d’établir le bit CE dans les en-têtes de paquet.

Durant les périodes de taux de marquage de paquet faible ou modéré lorsque ECN est déployé, il y a peu d’effet de dissuasion sur les flux insensibles d’abandonner plutôt que de marquer ces paquets. Par exemple, les flux insensibles au retard utilisant la livraison fiable pourraient avoir une incitation à augmenter plutôt qu’à diminuer leur taux d’envoi en présence d’abandon de paquets. De même, les flux sensibles au délai qui utilisent une livraison non fiable pourraient augmenter leur utilisation de la FEC en réponse à une augmentation du taux d’abandon de paquets, accroissant plutôt que diminuant leur taux d’envoi. Pour les mêmes raisons, on ne pense pas que l’abandon de paquets soit par lui-même une dissuasion efficace contre la non-conformité même dans un environnement de forts taux d’abandon de paquet.

Plusieurs méthodes ont été proposées pour identifier et restreindre les flux non conformes ou insensibles. L’ajout de ECN à l’environnement de réseau ne va en aucune manière augmenter la difficulté de la conception et du déploiement de tels mécanismes. Le seul effet de l’ajout de ECN à l’architecture sera de faire légèrement plus facilement le travail d’identification des flux insensibles. Par exemple, dans un environnement à capacité ECN, les routeurs ne se limitent pas aux informations sur les paquets qui sont abandonnés ou ont le bit CE mis chez ce routeur lui-même ; dans un tel environnement, les routeurs peuvent aussi prendre note des paquets CE arrivants qui indiquent de l’encombrement rencontré par ce paquet plus tôt sur le chemin.

10.   Non conformité dans le réseau

La rupture de l’efficacité du contrôle d’encombrement pourrait être causée non seulement après un point d’extrémité non conforme, mais aussi par la perte de l’indication d’encombrement dans le réseau lui-même. Cela pourrait arriver à cause d’un routeur malveillant ou en dérangement qui règle le bit ECT dans un paquet provenant d’un transport sans capacité ECN, ou qui "écrase" le bit CE dans les paquets arrivants. Par exemple, un routeur malveillant ou en dérangement qui "écrase" le bit CE dans des paquets CE arrivants empêcherait que l’indication d’encombrement arrive sur les receveurs vers l’aval. Il pourrait en résulter la défaillance du contrôle d’encombrement pour ce flux et une augmentation résultante de l’encombrement dans le réseau, causant finalement l’abandon des paquets suivants pour ce flux à mesure qu’augmente la taille moyenne de la file d’attente à la passerelle encombrée.

Les actions d’un routeur malveillant ou en dérangement pourraient aussi résulter en indications d’encombrement inutiles aux nœuds d’extrémité. Ces actions peuvent inclure l’abandon d’un paquet par un routeur ou en l’établissement du bit CE en l’absence d’encombrement. Du point de vue du contrôle de l’encombrement, l’établissement du bit CE en l’absence d’encombrement par un routeur non conforme ne serait pas différent de l’abandon inutile d’un paquet par un routeur. En "écrasant" le bit ECT d’un paquet qui est ensuite éliminé dans le réseau, l’action d’un routeur pourrait résulter en une élimination inutile du paquet plus tard dans le réseau.

Les problèmes qui concernent la perte des indications d’encombrement à partir de paquets encapsulés, éliminés, ou corrompus sont exposés ci-dessous.

10.1   Paquets encapsulés

Il faut veiller à traiter les bits CE et ECT de façon appropriée lorsque les paquets sont encapsulés et désencapsulés pour les tunnels.

Lorsque un paquet est encapsulé, les règles suivantes s’appliquent à l’égard du bit ECT. D’abord, si le bit ECT dans l’en-tête encapsulé ('intérieur) est un 0, le bit ECT dans l’en-tête encapsulant ("extérieur") DOIT alors être un 0. Si le bit ECT dans l’en-tête intérieur est un 1, le bit ECT dans l’en-tête extérieur DEVRAIT alors être un 1.

Lorsque un paquet est désencapsulé, les règles suivantes s’appliquent à l’égard du bit CE. Si le bit ECT est un 1 dans l’en-tête intérieur et dans l’en-tête extérieur, le bit CE dans l’en-tête extérieur DOIT être combiné par l’opérateur OUX avec le bit CE dans l’en-tête intérieur. (C’est-à-dire, dans ce cas un bit CE de 1 dans l’en-tête extérieur doit être copié dans l’en-tête intérieur.) Si le bit ECT dans l’un ou l’autre en-tête est un 0, le bit CE dans l’en-tête extérieur est alors ignoré. Cette exigence pour le traitement des paquets désencapsulés ne s’applique pas actuellement aux tunnels IPsec.

Un exemple spécifique de l’utilisation de ECN avec l’encapsulation survient lorsque un flux souhaite utiliser la capacité ECN pour éviter le danger d’un abandon inutile de paquet pour le paquet encapsulé par suite d’encombrement à un nœud intermédiaire dans le tunnel. Cette fonctionnalité peut être prise en charge en copiant le champ ECN de l’en-tête IP interne dans l’en-tête IP externe lors de l’encapsulation, et en utilisant le champ ECN de l’en-tête IP externe pour régler le champ ECN dans l’en-tête IP interne lors de la désencapsulation. Cela permet effectivement aux routeurs le long du tunnel de faire que le bit CE soit établi dans le champ ECN de l’en-tête IP non encapsulé d’un paquet à capacité ECN lorsque de tels routeurs rencontrent de l’encombrement.

10.2   Considérations sur les tunnels IPsec

Tel que défini par les [RFC2406] et [RFC2402], le protocole IPsec n’inclut pas le champ ECN de l’en-tête IP dans ses calculs cryptographiques (dans le cas du mode tunnel, le champ ECN de l’en-tête IP extérieur n’est pas inclus). Donc, la modification du champ ECN par un nœud du réseau n’a pas d’effet sur la sécurité de bout en bout d’IPsec, parce qu’elle ne peut causer l’échec d’aucune vérification d’intégrité IPsec. Par conséquent, IPsec ne donne aucune défense contre une modification hostile du champ ECN (c’est-à-dire, une attaque par interposition), car la modification hostile n’aura aussi aucun effet sur la sécurité de bout en bout d’IPsec. Dans certains environnements, la capacité à modifier le champ ECN sans affecter les vérifications d’intégrité d’IPsec constitue un canal caché; si il est nécessaire d’éliminer un tel canal ou de réduire sa bande passante, le champ ECN de l’en-tête IP extérieur peut être mis à zéro aux nœuds d’entrée et de sortie du tunnel.

Le protocole IPsec exige actuellement que le champ ECN de l’en-tête interne ne soit pas changé par le processus de désencapsulation IPsec au nœud de sortie d’un tunnel. Cela garantit que des modifications hostiles du champ ECN ne peuvent pas être utilisées pour lancer des attaques de vol ou de déni de service à travers un point d’extrémité de tunnel IPsec, car de telles modifications seront éliminées au point d’extrémité du tunnel. Le présent document n’apporte pas de changement à cette exigence d’IPsec. Par suite de la spécification actuelle du protocole IPsec, nous suggérons de ne pas faire pour l’instant d’expériences avec ECN sur des flux qui devraient passer par un tunnel IPsec.

Si les spécifications d’IPsec sont modifiées à l’avenir pour permettre à un nœud de sortie de tunnel de modifier le champ ECN dans un en-tête IP intérieur sur la base de la valeur du champ ECN dans l’en-tête extérieur (par exemple, en copiant tout ou partie du champ ECN externe dans le champ ECN interne), ou en permettant que le champ ECN de l’en-tête IP externe soit mis à zéro durant l’encapsulation, des expériences sur ECN pourront être utilisées en combinaison avec le tunnelage IPsec.

Cette discussion sur les relations entre ECN et le tunnel IPsec s’est fortement appuyée sur les discussions et documents du groupe de travail Services différenciés.

10.3   Paquets abandonnés ou corrompus

Un problème supplémentaire concerne le paquet qui a le bit CE établi à un routeur et est éliminé par un routeur suivant. Pour l’utilisation proposée de ECN dans le présent mémoire (c’est-à-dire, pour un protocole de transport comme TCP pour lequel un paquet de données abandonné est une indication d’encombrement), les nœuds d’extrémité détectent les paquets de données abandonnés, et la réponse d’encombrement des nœuds d’extrémité à un abandon de paquet de données est au moins aussi forte que la réponse d’encombrement à la réception d’un paquet CE.

Cependant, les protocoles de transport tels que TCP ne détectent pas nécessairement tous les abandons de paquet, tels que l’abandon d’un paquet ACK "pur" ; par exemple, TCP ne réduit pas le taux d’arrivée des paquets ACK suivants en réponse à un abandon antérieur de paquet ACK. Toute proposition d’extension de la capacité ECN à de tels paquets devrait régler les probèmes soulevés par les paquets CE qui sont ensuite éliminés dans le réseau.

De même, si un paquet CE est abandonné plus tard dans le réseau à cause d’une corruption (des erreurs binaires), les nœuds d’extrémité devraient encore invoquer le contrôle d’encombrement, tout comme TCP aujourd’hui, en réponse à un abandon de paquet de données. Cette question des paquets CE corrompus devrait être prise en considération dans toute proposition de distinction par le réseau entre paquets abandonnés à cause de leur corruption, et paquets abandonnés à cause de l’encombrement ou au débordement de mémoire tampon.

11.   Résumé des travaux connexes

[Floyd94] considère les avantages et les inconvénients de l’ajout de ECN à l’architecture TCP/IP. Comme le montrent les comparaisons fondées sur la simulation, un des avantages de ECN est d’éviter des abandons de paquet inutiles pour les connexions TCP courtes ou sensibles au retard. Un second avantage de ECN est d’éviter certaines temporisations de retransmission inutiles dans TCP. Le présent mémoire expose en détail l’intégration de ECN dans le mécanisme de contrôle de l’encombrement de TCP. L’inconvénient possible de ECN discuté dans ce mémoire est qu’une connexion non conforme à TCP pourrait faussement s’annoncer elle-même comme à capacité ECN, et qu’un paquet ACK TCP portant un message ECN-Echo pourrait être lui-même abandonné dans le réseau. Le premier de ces problèmes est discuté à la Section 8 du présent document, et le second est traité par la proposition, au paragraphe 5.1.3, par un fanion CWR dans l’en-tête TCP.

[CKLTZ97] rapporte une mise en œuvre expérimentale de ECN dans IPv6. L’expérience comporte la mise en œuvre de ECN dans une mise une œuvre existante de RED pour FreeBSD. Un certain nombre d’expériences ont été effectuées pour démontrer le contrôle de la taille moyenne de la file d’attente dans le routeur, les performances de ECN pour une seule connexion TCP avec un routeur encombré, et l’équité du traitement avec plusieurs connexions TCP en compétition. Une conclusion de ces expériences est que l’abandon de paquet provenant d’un transfert de données brutes peut dégrader les performances beaucoup plus sévèrement que le marquage des paquets.

Comme la mise en œuvre expérimentale de [CKLTZ97] précède certains des développements du présent document, elle ne se conforme pas à tous égards à ce document. Par exemple, dans la mise en œuvre expérimentale, le fanion CWR n’est pas utilisé, et le receveur TCP envoie à la place le bit ECN-Echo sur un seul paquet ACK.

[K98] et [CKLTZ98] sont partis de [CKLTZ97] pour poursuivre l’analyse des bénéfices de ECN pour TCP. La conclusion est que ECN TCP obtient un débit légèrement meilleur qu’un TCP non ECN ; que les flux ECN TCP sont équitables à l’égard des flux TCP non ECN ; et que TCP ECN est robuste avec le trafic bidirectionnel, en présence d’encombrement dans les deux directions, et de plusieurs passerelles encombrées. Les expériences avec plusieurs transferts courts sur la toile montrent que, bien que la plupart des connexions courtes aient des temps de transfert similaires avec ou sans ECN, un faible pourcentage des connexions courtes a des temps de transfert très longs pour les expériences non ECN par rapport aux expériences ECN. Cette augmentation du temps de transfert est particulièrement saisissante pour les courtes connexions qui ont leur premier paquet abandonné dans l’expérience non ECN, et ont donc à attendre six secondes l’expiration du temporisateur de retransmission.

La page ECN de la Toile [ECN] a des pointeurs sur d’autres mises en œuvre d’ECN en cours.

12.   Conclusions

Étant données les efforts actuels pour mettre en œuvre RED, nous pensons que c’est le bon moment pour les fabricants de routeurs d’examiner comment mettre en œuvre les mécanismes d’évitement d’encombrement qui ne dépendent pas seulement de l’abandon de paquet. Avec le déploiement accru d’applications et de transports sensibles au retard et à la perte d’un seul paquet (par exemple, le trafic en temps réel, les transferts courts sur la Toile), il apparaît que dépendre de la seule perte de paquet comme mécanisme normal de notification d’encombrement est insuffisant (ou à tout le moins, sous optimal).

13.   Remerciements

De nombreuses personnes ont fait des contributions à la présente RFC. Nous tenons à remercier en particular Kenjiro Cho pour la proposition du mécanisme TCP pour négocier la caapcité ECN, Kevin Fall pour la proposition du bif CWR, Steve Blake pour les matériaux sur le recalcul de la somme de contrôle d'en-tête IPv4, Jamal Hadi Salim pour l'exposé sur les problèmes d'ECN, et Steve Bellovin, Jim Bound, Brian Carpenter, Paul Ferguson, Stephen Kent, Greg Minshall, et Vern Paxson pour l'exposé sur les questions de sécurité. Nous remercions aussi le groupe de recherches sur l'Internet de bout en bout pour les discussions en cours sur ces questions.

14.   Références

[CKLT98]   Chen, C., Krishnan, H., Leung, S., Tang, N., and Zhang, L., "Implementing ECN for TCP/IPv6", présentation au BOF ECN à la réunion de mars 1998 de l'IETF à Los Angeles, URL "http://www.cs.ucla.edu/~hari/ecn-ietf.ps".

[ECN]   "The ECN Web Page", URL "http://www-nrg.ee.lbl.gov/floyd/ecn.html".

[FJ93]   Floyd, S., and Jacobson, V., "Random Early Detection gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, V.1 N.4, août 1993, p. 397-413. URL "ftp://ftp.ee.lbl.gov/papers/early.pdf".

[Floyd94]   Floyd, S., "TCP and Explicit Congestion Notification", ACM Computer Communication Review, V. 24 N. 5, octobre 1994, p. 10-23. URL "ftp://ftp.ee.lbl.gov/papers/tcp_ecn.4.ps.Z".

[Floyd97]   Floyd, S., and Fall, K., "Router Mechanisms to Support End-to-End Congestion Control", rapport technique, février 1997. URL "http://www-nrg.ee.lbl.gov/floyd/end2end-paper.html".

[Floyd98]   Floyd, S., "The ECN Validation Test in the NS Simulator", URL "http://www-mash.cs.berkeley.edu/ns/", test tcl/test/test-all-ecn.

[K98]   Krishnan, H., "Analyzing Explicit Congestion Notification (ECN) benefits for TCP", Thèse de maîtrise, UCLA, 1998, URL "http://www.cs.ucla.edu/~hari/software/ecn/ecn_report.ps.gz".

[FRED]   Lin, D., and Morris, R., "Dynamics of Random Early Detection", SIGCOMM '97, septembre 1997. URL "http://www.inria.fr/rodeo/sigcomm97/program.html#ab078".

[Jacobson88]   V. Jacobson, "Congestion Avoidance and Control", Proc. ACM SIGCOMM '88, pp. 314-329. URL "ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z".

[Jacobson90]   V. Jacobson, "Modified TCP Congestion Avoidance Algorithm". Message à la liste de diffusion end2end-interest, avril 1990. URL "ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt".

[MJV96]   S. McCanne, V. Jacobson, and M. Vetterli, "Receiver-driven Layered Multicast", SIGCOMM '96, août 1996, pp. 117-130.

[RFC0791]   J. Postel, éd., "Protocole Internet - Spécification du protocole du programme Internet", STD 5, septembre 1981.

[RFC0793]   J. Postel (éd.), "Protocole de commande de transmission – Spécification du protocole du programme Internet DARPA", (STD 7), septembre 1981.

[RFC1141]   T. Mallory et A. Kullberg, "Mise à jour incrémentaire de la somme de contrôle Internet", janvier 1990.

[RFC1349]   P. Almquist, "Type de service dans la suite de protocole Internet", juillet 1992. (Remplacée par 2474)

[RFC1455]   D. Eastlake, "Type de service Sécurité de la liaison physique", mai 1993. (Remplacée par 2474)

[RFC2001]   W. Stevens, "Algorithmes de démarrage lent, d'évitement d'encombrement, de retransmission rapide et de récupération rapide dans TCP", janvier 1997. (Obsolète, voirRFC2581) (P.S.)

[RFC2119]   S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC2309]   B. Braden et autres, "Recommandations sur la gestion de file d'attente et l'évitement d'encombrement dans l'Internet", avril 1998.

[RFC2402]   S. Kent et R. Atkinson, "En-tête d'authentification IP", novembre 1998. (Obsolète, voir RFC4302, 4305)

[RFC2406]   S. Kent et R. Atkinson, "Encapsulation de charge utile de sécurité IP (ESP)", novembre 1998. (Obsolète, voir RFC4303)

[RFC2474]   K. Nichols, S. Blake, F. Baker et D. Black, "Définition du champ Services différenciés (DS Field) dans les en-têtes IPv4 et IPv6", décembre 1998. (MàJ parRFC3168, RFC3260) (P.S.)

[RJ90]   K. K. Ramakrishnan and Raj Jain, "A Binary Feedback Scheme for Congestion Avoidance in Computer Networks", ACM Transactions on Computer Systems, Vol.8, N° 2, pp. 158-181, mai 1990.

15.   Considérations pour la sécurité

Les considérations pour la sécurité sont exposées à la Section 9.

16.   Recalcul de la somme de contrôle d'en-tête IPv4

Le recalcul de la somme de contrôle d’en-tête IPv4 pose problème avec certaines architectures de touteur de niveau supérieur qui utilisent un commutateur à mémoire tampon de sortie, car la plus grande partie, sinon toute la manipulation d’en-tête est effectuée sur le côté entrée du commutateur, alors que la décision sur ECN devrait être en local sur la mémoire tampon de sortie. Ce n’est pas un problème pour IPv6, car il n’y a pas de somme de contrôle d’en-tête IPv6. L’octet TOS d’IPv4 est le dernier octet d’un demi mot de 16 bits.

La [RFC1141] discute de la mise à jour incrémentaire de la somme de contrôle IPv4 après la décrémentation du champ TTL. La mise à jour incrémentaire de la somme de contrôle IPv4 après l’établissement du bit CE pourrait fonctionner comme suit : Soit HC la somme de contrôle d’en-tête originale, et soit HC' la nouvelle somme de contrôle d’en-tête après l’établissement du bit CE. Pour les sommes de contrôle d’en-tête calculées avec la soustraction du complément à un, HC' serait recalculé comme suit :

HC' = { HC - 1 HC > 1

{ 0x0000 HC = 1

Pour les sommes de contrôle d’en-tête calculées sur les machines à complément à deux, HC' serait recalculé comme suit après l’établissement du bit CE :

HC' = { HC - 1 HC > 0

{ 0xFFFE HC = 0

17.   Motifs du bit ECT

Le besoin du bit ECT est motivé par le fait que ECN sera déployé de façon incrémentaire dans l’Internet où certains protocoles de transport et routeurs comprennent ECN et certains ne le comprennent pas. Avec le bit ECT, le routeur peut abandonner les paquets de flux sans capacité ECN, mais peut *à la place* établir le bit CE dans des flux qui *sont* à capacité ECN. Comme le bit ECT permet à un nœud d’extrémité d’avoir le bit CE établi dans un paquet *au lieu* de voir le paquet éliminé, un nœud d’extrémité pourrait avoir une incitation à déployer ECN.

Si il n’y a pas d’indication ECT, le routeur devra alors établir le bit CE pour les paquets de flux aussi bien à capacité ECN que sans capacité ECN. Dans ce cas, il n’y aurait pas d’incitation pour que les nœuds d’extrémité déploient ECN, et pas de chemin viable de déploiement incrémentaire d’un monde sans ECN à un monde à capacité ECN. Considérons les premières étapes d’un tel déploiement incrémentaire, où un sous ensemble des flux est à capacité ECN. Au début de l’encombrement, lorsque le taux de marquage/abandon de paquet est encore faible, les routeurs vont seulement établir les bits CE, plutôt que d’abandonner les paquets. Cependant, seuls les flux à capacité ECN vont comprendre, et répondre aux paquets CE. Le résultat est que les flux à capacité ECN vont réduire, et les flux sans capacité ECN ne seront pas au courant des signaux ECN et vont continuer d’ouvrir leur fenêtre d’encombrement.

Dans ce cas, il y a deux résultats possibles : (1) les flux à capacité ECN réduisent et les flux sans capacité ECN obtiennent toute la bande passante, l’encombrement restant moyen, ou (2) les flux à capacité ECN réduisent, les flux sans capacité ECN ne le font pas, et l’encombrement augmente jusqu’à ce que le routeur passe de l’établissement du bit CE à l’abandon de paquets. Bien que le second résultat égalise les chances, les flux à capacité ECN vont tirer peu d’avantages d’être à capacité ECN, parce que l’augmentation de l’encombrement va conduire le routeur à un comportement d’abandon de paquets.

Un flux qui s’est annoncé comme à capacité ECN mais ne répond pas aux bits CE est fonctionnellement équivalent à un flux qui désactive le contrôle d’encombrement, comme exposé aux Sections 8 et 9.

Donc, dans un monde où un sous ensemble des flux est à capacité ECN, mais où les flux à capacité ECN n’ont pas de mécanisme pour indiquer ce fait aux routeurs, il y aurait un contrôle d’encombrement moins efficace et moins équitable dans l’Internet, résultant en une forte incitation des nœuds d’extrémité à ne pas déployer ECN.

18.   Pourquoi utiliser deux bits dans l'en-tête IP ?

Étant donné le besoin d’une indication ECT dans l’en-tête IP, il reste encore la question de savoir pourquoi les indications ECT (Transport à capacité ECN) et CE (Encombrement rencontré) devraient être surchargées sur un seul bit. Cette autre solution de la surcharge d’un seul bit est explorée dans [Floyd94], et elle impliquerait un seul bit avec deux valeurs. Une valeur, "ECT et pas CE", représenterait un transport à capacité ECN, et l’autre valeur, "CE ou pas ECT", représenterait soit Encombrement rencontré, soit un transport sans capacité ECN.

Une différence entre les mises en œuvre à un bit et à deux bits concerne les paquets qui traversent plusieurs routeurs encombrés. Considérons un paquet CE qui arrive à un second routeur encombré, et qui est choisi par la gestion active de file d’attente du routeur pour être marqué ou éliminé. Dans la mise en œuvre à un bit, le second routeur encombré n’a pas d’autre choix que d’éliminer le paquet CE, parce qu’il ne peut pas distinguer entre un paquet CE et un paquet non ECT. Dans la mise en œuvre à deux bits, le second routeur encombré a le choix d’éliminer le paquet CE ou de le laisser passer avec le bit CE établi.

Un autre différence entre les mises en œuvre à un et deux bits vient du fait qu’avec la mise en œuvre à un bit, les receveurs dans un seul flux ne peuvent pas distinguer entre les paquets CE et non ECT. Donc, dans la mise en œuvre à un bit, un envoyeur de données à capacité ECN devra indiquer de façon non ambiguë au ou aux receveurs si chaque paquet a été envoyé avec ou sans la capacité ECN. Une possibilité serait que l’envoyeur indique dans l’en-tête de transport si le paquet est envoyé avec la capacité ECN. Une seconde possibilité qui impliquerait une limitation fonctionnelle de la mise en œuvre à un bit, serait que l’envoyeur indique sans ambiguïté qu’il va envoyer *tous* ses paquets avec la capacité ECN ou sans la capacité ECN. Pour un protocole de transport en diffusion groupée, cette indication non ambiguë serait apparente aux receveurs qui se joignent à une session en diffusion groupée en cours.

Un autre avantage de l’approche à deux bits est qu’elle est sensiblement plus robuste. La question la plus critique, discutée à la Section 8, est que l’indication par défaut devrait être un transport sans capacité ECN. Dans une mise en œuvre à deux bits, cette exigence de la valeur par défaut signifie simplement que le bit ECT devrait être non établi par défaut. Dans la mise en œuvre à un bit, cela signifie que le seul bit surchargé devrait pas défaut être dans la position "CE ou non ECT". Cela est moins clair et direct, et éventuellement plus ouvert à des mises en œuvre incorrectes aux nœuds d’extrémité ou aux routeurs.

En résumé, bien que la mise en œuvre à un bit soit possible, elle a les limitations significatives suivantes par rapport à la mise en œuvre à deux bits. D’abord, la mise en œuvre à un bit a des fonctionnalités plus limitées pour le traitement des paquets CE à un second routeur encombré. Ensuite, la mise en œuvre à un bit exige soit que des informations supplémentaires soient portées dans l’en-tête de transport des paquets provenant de flux à capacité ECN (pour convoyer la fonctionnalité du second bit ailleurs, à savoir dans l’en-tête de transport), ou que les envoyeurs dans les flux à capacité ECN acceptent la limitation que les receveurs doivent être capables de déterminer a priori quels paquets sont à capacité ECN et quels paquets ne le sont pas. Enfin, la mise en œuvre à un bit est éventuellement plus encline aux erreurs de la part de mises en œuvre fautives qui choisissent la mauvaise valeur par défaut pour le bit ECN. Nous pensons que l’utilisation de bits supplémentaires dans l’en-tête IP pour le bit ECT est extrêmement précieuse pour surmonter ces limitations.

19.   Définitions historiques de l'octet TOS IPv4

La [RFC791] définissait l’octet ToS (Type de service) dans l’en-tête IP. Dans la RFC 791, les bits 6 et 7 de l’octet ToS sont indiqués comme "Réservés pour utilisation future ", et sont montrés comme mis à zéro. Les deux premiers champs de l’octet ToS étaient définis comme les champs Préséance et Type de service (TOS).

    0     1    2     3     4     5     6     7

+-----+-----+-----+-----+-----+-----+-----+-----+

|    PRESEANCE    |        TOS      |  0  |  0  | RFC 791

+-----+-----+-----+-----+-----+-----+-----+-----+

La RFC 1122 incluait les bits 6 et 7 dans le champ TOS, bien qu’elle n’expose aucune utilisation spécifique de ces deux bits :

    0     1     2     3     4     5     6     7

+-----+-----+-----+-----+-----+-----+-----+-----+

|    PRESEANCE    |             TOS             | RFC 1122

+-----+-----+-----+-----+-----+-----+-----+-----+

L’octet TOS IPv4 a été redéfini comme suit dans la [RFC1349]:

    0     1     2     3     4     5     6     7

+-----+-----+-----+-----+-----+-----+-----+-----+

|    PRESEANCE    |             TOS       | MBZ | RFC 1349

+-----+-----+-----+-----+-----+-----+-----+-----+

Le bit 6 du champ TOS a été défini dans la RFC 1349 comme "Minimise le coût monétaire". En plus des champs Préséance et Type de service (TOS), le dernier champ, MBZ (pour "must be zero") était défini comme actuellement non utilisé. La RFC 1349 déclarait que "le générateur d’un datagramme règle le champ [MBZ] à zéro (sauf participation à un protocole expérimental de l’Internet qui utiliserait ce bit)."

La [RFC1455] définissait une norme expérimentale qui utilisait les quatre bits du champ TOS pour demander un niveau garanti de sécurité de la liaison.

La RFC1349 est rendue obsolète par la "Définition du champ de services différenciés (champ DS) dans les en-têtes IPv4 et IPv6 " [RFC2474], dans laquelle les bits 6 et 7 du champ DS sont désignés comme Actuellement inutilisé (CU, Currently Unused). Les six premiers bits du champ DS sont définis comme le codet de services différenciés (DSCP, Differentiated Services CodePoint) :

    0     1     2     3     4     5     6     7

+-----+-----+-----+-----+-----+-----+-----+-----+

|                DSCP               |    CU     |

+-----+-----+-----+-----+-----+-----+-----+-----+

À cause de cette histoire instable, il ne peut être garanti que la définition du champ ECN dans le présent document est rétro compatible avec toutes les utilisations passées de ces deux bits. Les dommages qui pourraient être causés par un routeur sans capacité ECN seraient "d’écraser" le bit CE pour un paquet à capacité ECN qui arriverait au routeur avec le bit CE établi, ou d’établir le bit CE même en l’absence d’encombrement. Cela a été exposé à la Section 10 "Non-conformité dans le réseau ".

Le dommage qui pourrait être causé dans un environnement à capacité ECN par un nœud d’extrémité sans capacité ECN qui transmet des paquets avec le bit ECT établi a été exposé à la Section 9 "Non-conformité des nœuds d’extrémité".

Adresse des auteurs

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (1999). Tous droits réservés.

Ce document et ses traductions peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant la notice de droits d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus des normes pour l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet, ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.

Remerciement

Le financement de la fonction d'éditeur des RFC est actuellement assuré par la Internet Society.