Tunneling ECN RFC 6040 et L4S RFC 9330 : DualQ AQM et VPN basse latence

Pendant des décennies, la réponse par défaut des infrastructures réseau face à la saturation des liaisons a été radicale : rejeter le paquet (packet drop). Sous la gestion classique des files d'attente Drop-Tail et les algorithmes de contrôle de congestion basés sur les pertes comme TCP Reno et Cubic, un routeur encombré signale la saturation en saturant sa mémoire tampon jusqu'à ce que les paquets entrants soient abandonnés. L'émetteur détecte l'absence d'acquittement (ACK), en déduit un goulot d'étranglement, réduit de moitié sa fenêtre de congestion (cwnd) et déclenche des retransmissions.

Bien que cette boucle de rétroaction empêche l'effondrement global du réseau, elle induit des pénalités opérationnelles considérables. Dans les applications interactives — voix en direct, visioconférence, jeu en ligne compétitif et transactions financières — la perte de paquets génère des pics de latence immédiats et de la gigue (jitter). Lorsque le trafic transite par des tunnels VPN chiffrés (tels qu'IPsec ou WireGuard), le phénomène de saturation des tampons (bufferbloat) et les pertes s'amplifient en raison de l'encapsulation superposée.

Afin de dissocier la notification d'encombrement de la perte de paquets, l'IETF a standardisé la notification explicite de congestion (ECN - Explicit Congestion Notification) dans la RFC 3168, puis en a affiné la propagation en tunnel dans la RFC 6040. Sur ces bases, le cadre L4S (Low Latency, Low Loss, Scalable Throughput, défini dans les RFC 9330, RFC 9331 et RFC 9332) introduit la gestion de file couplée DualQ Coupled AQM, permettant de maintenir une latence d'attente inférieure à une milliseconde sur les liaisons directes comme dans les architectures VPN sécurisées.

Le paradigme de la perte de paquets : pourquoi le Drop-Tail échoue sur les réseaux modernes

Dans les architectures réseau traditionnelles, l'occupation des files d'attente oscille entre deux extrêmes néfastes. Lorsque les tampons sont trop réduits, les rafales de trafic soudaines ne peuvent être absorbées, entraînant des rejets prématurés et une sous-utilisation de la bande passante. À l'inverse, lorsque les équipementiers et opérateurs surdimensionnent la mémoire tampon pour éviter toute perte, ils engendrent le bufferbloat.

En situation de bufferbloat, les routeurs intermédiaires accumulent des mégaoctets de paquets lors des transferts massifs. Les données stagnent dans la mémoire physique pendant des centaines de millisecondes en attendant leur sérialisation sur le support physique. Pour le trafic UDP interactif partageant ce chemin, ce délai dégrade sévèrement la réactivité. Le temps d'aller-retour effectif ($RTT$) augmente selon la relation :

$$RTT_{\text{actual}} = RTT_{\text{propagation}} + \frac{Q_{\text{bytes}}}{\text{Bandwidth}}$$

Lorsque la file finit par déborder, le rejet massif de paquets provoque une synchronisation globale du ralentissement TCP sur l'ensemble des sessions concurrentes. La liaison entre dans un cycle instable d'engorgement, de variation de latence, de perte de paquets et de chute de débit. La gestion Drop-Tail fait de la détérioration du réseau un prérequis au contrôle de flux.

Architecture ECN : le champ IP à 2 bits et la négociation TCP (RFC 3168)

La RFC 3168 élimine la nécessité d'abandonner volontairement des paquets en intégrant la notification explicite directement dans l'en-tête IP. La norme réutilise les deux bits de poids faible de l'octet ToS (Type of Service) en IPv4 et du champ Traffic Class en IPv6 :

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|      DSCP (6 bits)    |  ECN  |
+---+---+---+---+---+---+---+---+

Le champ ECN de 2 bits définit quatre points de code opérationnels distincts :

Valeur binaire	Symbole	Signification protocolaire
`00`	Non-ECT	Transport non compatible ECN (gestion par rejet classique)
`01`	ECT(1)	Transport compatible ECN (dédié aux flux évolutifs L4S)
`10`	ECT(0)	Transport compatible ECN (rétroaction classique RFC 3168)
`11`	CE	Congestion rencontrée (Congestion Experienced, marqué par les routeurs)

Avant d'utiliser ECN sur une connexion TCP de bout en bout, les extrémités négocient cette capacité lors de la poignée de main initiale à trois voies (three-way handshake) :

Paquet SYN : Le client active simultanément les indicateurs ECE (ECN-Echo) et CWR (Congestion Window Reduced) dans l'en-tête TCP pour proposer la prise en charge d'ECN.
Paquet SYN-ACK : Si le serveur supporte ECN, il répond avec le drapeau ECE activé et le drapeau CWR désactivé.
Paquet ACK : Le client finalise l'établissement sans ces drapeaux, basculant la transmission de données en mode ECN actif.

Client                                                  Serveur
  |--- SYN [ECE=1, CWR=1] ------------------------------->| (Proposition ECN)
  |<-- SYN-ACK [ECE=1, CWR=0] ----------------------------| (Acceptation ECN)
  |--- ACK [ECE=0, CWR=0] ------------------------------->| (Connexion prête)
  |                                                       |
  |=== Paquet de données [IP: ECT(0)] ===================>| (File intermédiaire marque CE)
  |<== Accusé de réception [TCP: ECE=1] ==================| (Renvoi du signal de congestion)
  |--- Paquet de données [TCP: CWR=1, IP: ECT(0)] ------->| (Confirmation réduction fenêtre)

En cours de transfert, un routeur intermédiaire constatant une accumulation en file réécrit le champ IP de ECT(0) ou ECT(1) vers CE (11) au lieu de détruire le datagramme. Dès réception d'un paquet portant la marque CE, le récepteur active l'indicateur ECE dans les accusés de réception suivants. L'émetteur ajuste sa fenêtre d'émission et transmet avec le fanion CWR pour confirmer la prise en compte.

Le dilemme de l'encapsulation en tunnel : perte des marques et trous noirs

Si la RFC 3168 définissait clairement les règles pour des liaisons IP point à point non encapsulées, elle laissait des incertitudes majeures concernant les tunnels. L'encapsulation constitue le socle des réseaux privés virtuels, où un paquet IP interne est imbriqué dans un paquet de transport externe (tel qu'IPsec ESP, WireGuard UDP, GRE ou GENEVE).

Lorsqu'un paquet encapsulé traverse un routeur intermédiaire congestionné, celui-ci marque l'en-tête IP externe avec la valeur CE (11). Cependant, le traitement lors de la désencapsulation à la sortie du tunnel a longtemps souffert de deux anomalies majeures :

Perte du signal (cécité ECN) : La passerelle de sortie retirait l'en-tête IP externe et transmettait le paquet interne avec ses indicateurs d'origine (ECT(0) ou Not-ECT). L'alerte CE disparaissait lors du désencapsulage. L'engorgement persistait jusqu'à saturation physique de la mémoire tampon et perte brutale de paquets.
Copie incontrôlée (trou noir ECN) : Le routeur d'entrée copiait aveuglément les bits ECN internes vers l'extérieur sans vérifier si le protocole interne supportait ECN. Si un paquet non compatible (00) voyait son enveloppe externe marquée CE, la réinjection directe du signal CE vers un hôte ancien perturbait la pile réseau.

Ces anomalies ont historiquement conduit de nombreux administrateurs à désactiver ECN dans les déploiements VPN d'entreprise.

Spécification RFC 6040 : mode Normal, mode Compatibilité et désencapsulation Egress

La RFC 6040 a résolu ce dilemme d'encapsulation en établissant des règles strictes et indépendantes du protocole sous-jacent pour la gestion des points de code ECN à l'entrée (Ingress) et à la sortie (Egress) du tunnel.

Règles d'encapsulation Ingress : mappage de l'ECT interne vers l'en-tête externe

À l'entrée du tunnel, l'encapsulateur détermine les bits ECN de l'en-tête externe en fonction du paquet interne et du mode configuré :

Mode Normal (Normal Mode - Standard RFC 6040) : Si le paquet interne est Not-ECT (00), l'en-tête externe DOIT impérativement être configuré à Not-ECT (00). Cela garantit que les routeurs en aval rejetteront le paquet en cas de forte congestion, car le destinataire final ne sait pas interpréter le code CE. Si le paquet interne est ECT(0), ECT(1) ou CE, l'en-tête externe reflète fidèlement cette valeur.
Mode Compatibilité (Compatibility Mode) : Utilisé lorsque la conformité de la passerelle distante à la RFC 6040 ne peut être garantie. L'en-tête externe est forcé à Not-ECT (00) pour tous les paquets, obligeant le réseau à utiliser le mécanisme classique de rejet.

Table de vérité Egress : combinaison du CE externe avec l'état interne

À la sortie du tunnel, le désencapsulateur combine les codes ECN externe et interne avant de retirer l'enveloppe, selon la matrice de correspondance suivante :

En-tête interne	En-tête externe	En-tête transmis	Action et évaluation opérationnelle
`Not-ECT` (`00`)	`Not-ECT` (`00`)	`Not-ECT` (`00`)	Acheminement normal
`Not-ECT` (`00`)	`ECT(0)` / `ECT(1)`	`Not-ECT` (`00`)	Condition d'erreur : Externe indûment marqué ECT
`Not-ECT` (`00`)	`CE` (`11`)	ABANDON DU PAQUET	Rejet obligatoire : Externe saturé, interne incompatible CE
`ECT(0)` (`10`)	`Not-ECT` (`00`)	`ECT(0)` (`10`)	Acheminement normal : Traversée fluide
`ECT(0)` (`10`)	`ECT(0)` (`10`)	`ECT(0)` (`10`)	Transit nominal sans encombrement
`ECT(0)` (`10`)	`CE` (`11`)	`CE` (`11`)	Propagation de l'alerte vers le flux interne
`ECT(1)` (`01`)	`CE` (`11`)	`CE` (`11`)	Propagation de l'alerte vers le flux interne
`CE` (`11`)	`Not-ECT` (`00`)	`CE` (`11`)	Préservation du signal interne préexistant
`CE` (`11`)	`CE` (`11`)	`CE` (`11`)	Préservation de la marque de congestion

L'exigence de sécurité fondamentale de la RFC 6040 figure à la ligne 3 : si un paquet interne non compatible est encapsulé et que l'enveloppe externe arrive marquée CE, la passerelle doit obligatoirement abandonner le paquet. Ce rejet stimule la détection de perte de l'émetteur hérité et empêche le gonflement silencieux de la file d'attente.

L'évolution vers L4S : faible latence, pertes minimes et débit évolutif (RFC 9330)

Si l'ECN classique élimine les pertes inutiles, il ne résout pas la latence d'attente. Les mécanismes TCP traditionnels assimilent une marque CE à une perte de paquet en divisant par deux la fenêtre d'émission. Cette sanction étant très forte, les routeurs devaient paramétrer des seuils élevés pour ne pas sous-exploiter la bande passante, tolérant 10 à 50 millisecondes de délai en file.

L'architecture L4S normalisée dans la RFC 9330 surmonte cette contrainte grâce à trois piliers interdépendants :

Contrôle de congestion évolutif (TCP Prague / QUIC L4S) : L'émetteur module son débit en continu grâce à une rétroaction proportionnelle à haute fréquence. Au lieu de diviser sa fenêtre par deux, Prague réagit aux marques CE par d'infimes ajustements (échelle $O(1)$), maintenant le remplissage de la file proche de zéro.
Point de code d'identification (RFC 9331) : L4S utilise la valeur ECT(1) (01) dans l'en-tête IP. Les routeurs distinguent ainsi les paquets L4S des flux classiques ECT(0) ou Not-ECT.
Gestion couplée DualQ Coupled AQM (RFC 9332) : La passerelle sépare le trafic en deux files logiques distinctes, isolant les flux à faible latence des transferts volumineux tout en garantissant un partage équitable de la capacité.

Flux de paquets IP entrants
       |
       v
+-----------------------+
| Classificateur (9331) |
+-----------------------+
       |               |
       | [ECT(1)]      | [Not-ECT, ECT(0)]
       v               v
+-------------+ +---------------+
| File L      | |    File C     |
| (Faible tam-| | (Grand tampon,|
| pon, Step)  | |  AQM classique|
+-------------+ +---------------+
       \               /
        \             /
         v           v
+-------------------------------+
| Ordonnanceur couplé (RFC 9332)|
+-------------------------------+
                |
                v  Sortie à débit nominal (<1ms de latence)

Gestion DualQ Coupled AQM : isoler les flux classiques et les flux Prague (RFC 9332)

La RFC 9332 spécifie l'algorithme DualQ Coupled Active Queue Management, permettant aux applications interactives exigeantes de cohabiter sur le même goulot d'étranglement physique que des téléchargements volumineux, sans dégradation mutuelle.

La file classique native : coexistence de FQ-CoDel et de PIE

La file classique (C-Queue) prend en charge les paquets Not-ECT et ECT(0). Elle exploite des algorithmes AQM reconnus tels que PIE ou FQ-CoDel.

La file C maintient une latence cible entre 10 ms et 20 ms. En cas d'encombrement, elle rejette les paquets Not-ECT ou marque ECT(0) avec une probabilité proportionnelle à la racine carrée de la fonction de congestion ($p_C$).

La file à faible latence : marquage par palier et tampons sous la milliseconde

La file à faible latence (L-Queue) gère exclusivement les paquets ECT(1). Le contrôle Prague réagissant promptement au moindre signal, cette file ne requiert pas de mémoire tampon profonde.

Elle applique un marquage par palier immédiat (Step Marking) : dès que la rétention dépasse un seuil minimal (généralement 500 microsecondes à 1 milliseconde), les paquets suivants sont instantanément marqués CE. Aucun paquet n'est abandonné tant que la mémoire physique n'est pas intégralement saturée.

Pour préserver l'équité de débit entre les deux files sans pénaliser les flux historiques, la RFC 9332 couple mathématiquement les probabilités de marquage :

$$p_L = k \times p_C^2$$

La probabilité de marquage dans la file L ($p_L$) s'ajuste dynamiquement au carré de la probabilité de congestion de la file C ($p_C$), garantissant un partage équilibré de la bande passante entre L4S et TCP Cubic.

Impact concret sur les performances : jeux en ligne, visiophonie et tunnels VPN

L'association du tunneling ECN conforme à la RFC 6040 et de l'ordonnancement L4S DualQ AQM apporte des gains mesurables sur les applications interactives.

Dans le jeu vidéo sur le cloud, les flux vidéo interactifs et les systèmes financiers, la variation du délai (gigue) s'avère bien plus pénalisante que la latence brute. Dans un tunnel conventionnel en mode Drop-Tail, un transfert de données en arrière-plan à 500 Mbps fait grimper le temps de réponse en jeu de 25 ms à plus de 200 ms par accumulation de paquets dans les tampons.

Avec le tunneling RFC 6040 et la gestion DualQ AQM :

Délai d'attente en file : Chute de 80–250 ms à moins d'une milliseconde.
Pertes de paquets : Tendent vers 0,00 % sous forte charge grâce au marquage CE.
Blocage en tête de ligne : Totalement éliminé, assurant la fluidité des flux vocaux et des commandes interactives.

De plus, l'intégration d'ECN au sein des tunnels complète efficacement les dispositifs de robustesse système, tels que la protection du noyau contre les paniques TCP SACK, en maintenant la stabilité des tampons de sockets.

Architecture RiceGuard : tunneling ECN conforme RFC 6040 et délestage DualQ

VPNRice intègre directement les principes des RFC 6040 et RFC 9330 au niveau de son plan de commutation de données propriétaire, RiceGuard.

Dans les implémentations VPN courantes, les en-têtes IP externes sont souvent délaissés lors des opérations cryptographiques. Lorsque le noyau Linux encapsule un paquet dans WireGuard UDP ou IPsec ESP, les configurations d'origine ne répercutent généralement pas le signal CE externe vers le socket applicatif au moment de la désencapsulation.

[ Espace utilisateur client : TCP Prague / QUIC ]
       |
       | (En-tête IP interne : point de code ECT(1))
       v
[ Moteur de tunnel client RiceGuard ]
       |
       | Encapsulation d'entrée (RFC 6040 Mode Normal)
       | Recopie intégrale de l'indicateur ECT(1) sur l'UDP/IP externe
       v
[ Chemin opérateur public avec goulot DualQ ]
       |
       | Saturation détectée : Le routeur intermédiaire applique CE (11)
       v
[ Passerelle frontière RiceGuard (cœur de désencapsulation) ]
       |
       | Matrice de combinaison Egress RFC 6040 :
       | Externe=CE + Interne=ECT(1) ---> Transmission interne avec marque CE (11)
       v
[ Serveur de destination / Infrastructure cloud ]
       |
       | Régulation précise du débit : Délai tampon additionnel = 0 ms

Au sein de l'architecture RiceGuard :

Traitement strict des règles Ingress/Egress RFC 6040 : La chaîne de traitement cryptographique inspecte les en-têtes internes et externes à la vitesse du matériel. Lorsqu'un paquet encapsulé arrive avec la marque CE, RiceGuard met à jour l'en-tête interne avant le routage.
Délégation matérielle DualQ : Sur les passerelles périphériques de VPNRice, le trafic entrant est ventilé dans les files DualQ par des filtres eBPF/XDP. Les paquets UDP interactifs, la voix en temps réel et les flux L4S empruntent des circuits dédiés, protégés des flux de masse.
Gestion intégrée du MTU : L'encapsulation applique un ajustement MSS dynamique, évitant que la fragmentation ne vienne altérer le positionnement des bits ECN.

Liste de vérification technique : configurer ECN et L4S sur Linux et passerelles VPN

Pour configurer et valider la prise en charge de la RFC 6040 et de L4S sur les systèmes Linux et les passerelles VPN, appliquez les étapes suivantes :

Activation générale d'ECN : Définissez net.ipv4.tcp_ecn = 1 dans /etc/sysctl.conf pour activer la négociation ECN entrante et sortante.
Vérification du noyau Linux : Assurez-vous d'utiliser une version 6.4 ou ultérieure du noyau pour disposer nativement de TCP Prague et de l'ordonnanceur DualQ AQM (sch_dualpi2).
Attribution de la file d'attente DualQ : Configurez la discipline de file sur l'interface physique et l'interface de tunnel :
```
tc qdisc add dev eth0 root dualpi2
```
Application de la RFC 6040 sur WireGuard/IPsec : Vérifiez que les en-têtes ECN ne sont pas tronqués lors de l'encapsulation (sysctl -w net.ipv4.conf.all.rp_filter=2 et audit des tables de routage).
Audit de négociation ECN : Utilisez tcpdump pour capturer la séquence SYN, SYN-ACK et ACK et vous assurer de l'activation des drapeaux ECE et CWR :
```
tcpdump -i any 'tcp[13] & 0xc0 != 0' -n -vv
```
Validation de la table de désencapsulation : Envoyez des paquets de test marqués CE sur l'enveloppe externe pour vérifier leur propagation dans l'en-tête interne à la sortie de l'interface tunnel.
Suivi des compteurs de marquage et de rejet : Supervisez les métriques d'interface pour confirmer que les congestions sont signalées par marquage CE plutôt que par abandon de paquets :
```
tc -s qdisc show dev eth0
```