ECN : contrôle de congestion « proactif »
TCP : performance et évolution du protocole

Comme nous l’avons vu dans Protocole de transport TCP(§ 5), TCP étant un protocole de bout en bout, il n’a en principe aucune connaissance de l’état d’engorgement des équipements d’interconnexion au long de la route ; les pertes de paquets IP sont le seul signal indiquant l’existence d’un problème de débordement des files d’attente (mémoire) dans un routeur intermédiaire. Lorsqu’il reçoit ce signal, l’émetteur TCP réagit en faisant du contrôle de congestion. Néanmoins, cette réaction est « tardive » dans le sens où elle ne permet pas d’éviter que la perte ait lieu : des ressources réseau auront été utilisées dans les routeurs « en amont » pour transporter un paquet qui sera perdu dans un routeur « en aval ».

C’est dans le but d’améliorer le transport des signaux de congestion vers l’émetteur TCP qu’un mécanisme dit de notification explicite de la congestion (Explicit Congestion Notification : ECN) a été proposé par l’IETF [13]. L’idée d’ECN est de faire participer les routeurs intermédiaires au processus de contrôle de la congestion, de sorte que l’émetteur TCP puisse apprendre que des files d’attente au long de la route sont en train de se remplir : de cette manière, l’émetteur pourra alors anticiper la congestion, en réduisant son débit avant que des paquets soient perdus, ce qui contribue à désengorger le réseau. De plus, puisque l’émetteur réagit de façon anticipée et donc il n’y a pas eu de perte, on évite la retransmission.

Du fait de l’intervention des routeurs, la technique ECN impose l’utilisation d’un champ de 2 bits de l’en-tête des paquets IP afin de transporter un signal (une « marque ») de congestion modérée ou naissante. Les extrémités TCP, quant à elles, vont employer tant ce champ qu’un autre de 2 bits dans l’en-tête...