C'est après une très longue genèse (ce document avait été
adopté par le groupe de travail il y a plus de quatre ans) que
voici les protocoles concrets pour la signalisation de la
ConEx (pour
Il n'y a pas besoin de négociation au début (section 1 du RFC),
comme avec les options TCP. Les émetteurs qui connaissent ConEx
utilisent les informations existantes (pertes de paquets et
Pour bien utiliser ConEx, le TCP de l'émetteur a besoin
d'informations. Bien qu'il ne soit pas indispensable, c'est mieux
si SACK (
La section 2 du RFC résume les modifications chez l'émetteur
TCP (le récepteur n'a pas besoin d'être changé pour ConEx). Le comportement de l'émetteur dépendra du fait que le
récepteur met en œuvre (ou pas) SACK et ECN. L'émetteur est
responsable du marquage des paquets (suivant l'encodage du
En cas de perte de paquets, l'émetteur va mettre le signal
ConEx
Si c'est par des marques ECN, et non pas par des pertes de
paquets, que l'émetteur a appris qu'il y avait congestion, il va
utiliser les marques ConEx
Dans tous les cas (perte de paquets ou bien ECN), les paquets
marqués ConEx devront également porter une marque
Un émetteur ConEx est aussi censé envoyer des
Les paquets contenant les signaux ConEx peuvent se perdre,
comme tous les paquets IP (section 5 du RFC). Cela peut mener à
des pénalités injustes (un émetteur détecte qu'il y a congestion
en aval, le signale avec un L ou un E, le paquet portant le signal
est perdu, un routeur qui fait de l'audit ConEx se dit alors « ah,
ah, il essaie de tricher, il n'a pas signalé la congestion »). Le
problème étant du second ordre (si la probabilité de perdre un
paquet est P, la probabilité qu'il y ait perte du paquet
Plus délicat, le problème de la fraîcheur des informations
ConEx (section 6 du RFC). Ces informations ne sont utiles que si
elles sont très récentes (typiquement moins d'un