TCP RACK-TLP RFC 8985 : Détection des Pertes par le Temps et Sondage dans les VPN

Pendant plus de trois décennies, la reprise après perte du protocole Transmission Control Protocol (TCP) a reposé sur une méthode de comptage empirique : lorsqu'un émetteur reçoit trois accusés de réception dupliqués (Duplicate ACK, DupACK), il présume qu'un segment intermédiaire a été abandonné et non simplement réordonné. Établie dans la RFC 5681, cette règle de comptage reposait sur l'hypothèse d'itinéraires Internet symétriques, de débits homogènes et d'inversions de paquets négligeables.

Sur les réseaux contemporains, ce modèle classique montre fréquemment ses limites. Les tunnels chiffrés, les cartes réseau à files multiples (multi-queue NIC), les réémissions sur la liaison radio Wi-Fi, l'agrégation de porteuses mobiles et les réseaux étendus définis par logiciel (SD-WAN) engendrent fréquemment des réordonnancements anodins de paquets. Une inversion passagère de deux paquets peut enclencher à tort la procédure Fast Retransmit, réduisant de moitié la fenêtre de congestion et bridant le débit. À l'inverse, lorsqu'une perte survient à l'extrémité d'une rafale (perte en queue, tail drop), le canal ne transporte plus de paquets ultérieurs susceptibles de déclencher trois DupACK. La session s'interrompt alors dans l'attente du temporisateur Retransmission Timeout (RTO), imposant une pause de deux cents millisecondes à une seconde entière.

Pour moderniser les mécanismes de transport, l'Internet Engineering Task Force a standardisé la RFC 8985 : L'algorithme de détection de perte RACK-TLP pour TCP. En substituant au comptage de séquences une déduction temporelle physique (Recent ACKnowledgment, RACK) et en déployant une sonde proactive de queue (Tail Loss Probe, TLP), la spécification RFC 8985 confère une robustesse accrue aux liaisons VPN confrontées aux variations de latence.

[Schéma historique : Seuil rigide de 3 accusés dupliqués]
Émetteur ──[P1]──[P2]──[P3]──[P4]──> Récepteur (P2 dépasse P1 lors du transit)
Émetteur <──[Ack 0]──[DupAck 0]──[DupAck 0]──[DupAck 0] (Fast Retransmit déclenché à tort !)
L'émetteur divise CWND par deux -> Effondrement du débit sur liaisons parallèles.

[RFC 8985 RACK : Déduction temporelle avec fenêtre de réordonnancement]
Émetteur ──[P1]──[P2]──────────────> Récepteur (P2 livré à T1, P1 reçu 2 ms plus tard)
L'émetteur reçoit l'ACK de P2 -> Évalue : Temps écoulé < Fenêtre RACK.
L'émetteur diffère la réémission -> L'ACK de P1 est reçu -> La fenêtre CWND reste intacte.

[RFC 8985 TLP : Sonde proactive lors d'une perte en fin de flux]
Émetteur ──[P1]──[P2]──────────────> Récepteur (P2 perdu ; aucun paquet ultérieur en vol)
TCP classique : Blocage complet de 200 à 1000 ms dans l'attente du temporisateur RTO.
RFC 8985 TLP :   Active le temporisateur PTO (~ 2*SRTT) -> Émet un segment sonde.
Le récepteur renvoie un DupACK -> RACK active Fast Recovery -> Latence réduite de 85%+.

Les limites du comptage de paquets : pourquoi les ACK dupliqués classiques échouent

Le modèle classique de détection de pertes a été conçu à une époque où les liaisons de bout en bout étaient constituées de routeurs à file unique et de liaisons dédiées. Dans de telles conditions, l'ordre des séquences était rigoureusement maintenu sauf en cas de saturation de mémoire tampon.

L'infrastructure actuelle s'appuie sur le traitement multiprocesseur des paquets, la répartition de charge multiparcours (ECMP) et des encapsulations dynamiques qui induisent d'infimes écarts de traitement entre cœurs d'exécution parallèles.

La vulnérabilité du seuil empirique de trois DupACK face au micro-désordre

La règle des trois accusés de réception dupliqués impose un arbitrage structurel délicat :

• Seuil trop bas (1 ou 2 DupACK) : De légers décalages sur les liaisons Wi-Fi ou LTE entraînent des réémissions inutiles. L'émetteur passe prématurément en phase Fast Recovery, réduit son seuil de démarrage lent (ssthresh) et surcharge les files d'attente.
• Seuil trop haut (3 DupACK) : Les échanges interactifs à faible volume en transit — tels que les frappes au clavier sous SSH, les échanges TLS ou les appels d'API RPC — ne génèrent pas trois duplicatas lors d'une perte, contraignant le flux à attendre l'expiration du RTO.

Lorsque les paquets franchissent des tunnels WireGuard, IPsec ESP ou OpenVPN, le traitement cryptographique distribué sur plusieurs cœurs entraîne fréquemment des inversions mineures. Un compteur statique ne peut faire la part entre ce désordre temporaire et une véritable disparition de paquet.

Les insuffisances de SACK lors des pertes en fin de flux et sur liaisons asymétriques

L'option d'accusé sélectif Selective Acknowledgment (RFC 2018) a amélioré la visibilité en signalant les blocs reçus de manière discontinue. Néanmoins, SACK demeure un système réactif passif : il ne fait que récapituler les numéros de séquence effectivement parvenus à destination.

Si la perte survient sur le dernier élément d'un envoi — par exemple la trame HTTP/2 finale d'une réponse ou un caractère individuel sous SSH — aucun paquet subséquent ne vient susciter l'émission d'un bloc SACK. Dans cette circonstance de perte terminale, SACK se révèle impuissant, laissant l'émetteur tributaire du temporisateur de la RFC 6298 :

$$RTO = \text{SRTT} + \max(G, 4 \times \text{RTTVAR})$$

La valeur minimale du paramètre $RTO$ étant généralement bornée à $200\text{ ms}$ au sein des systèmes d'exploitation, les pertes en queue créent une interruption sensible de l'interactivité.

Architecture fondamentale de la norme RFC 8985 : Recent ACKnowledgment (RACK)

La norme RFC 8985 dissocie l'identification des pertes du comptage des positions séquentielles, fondant son analyse sur les repères temporels réels de transmission et d'accusé de réception.

Inférence des pertes par horodatage physique au lieu du comptage des numéros

Le principe directeur de Recent ACKnowledgment (RACK) est particulièrement clair : si un segment transmis à l'instant $T_1$ a été validé par le récepteur, tout segment antérieur non acquitté est présumé perdu dès lors qu'un intervalle suffisant s'est écoulé depuis son départ.

Plutôt que d'évaluer le volume de paquets ayant dépassé le segment manquant, RACK surveille la chronologie des livraisons :

1. RACK.xmit_ts : Chaque segment transmis ou réémis reçoit une estampille temporelle de haute précision lors de son passage sur la pile réseau.
2. RACK.end_seq : Enregistre le numéro de séquence le plus élevé émis jusqu'alors.
3. RACK.rtt : Conserve la valeur de temps aller-retour la plus récente tirée des accusés entrants (par ACK cumulatif ou bloc SACK).
4. Condition de perte : Un segment non acquitté $S$ est déclaré perdu dès que : $$S.\text{xmit_ts} + \text{RACK.rtt} + \text{RACK.rwin} \le \text{Current_Time}$$ où $\text{RACK.rwin}$ représente la fenêtre adaptative de tolérance au désordre.

En se basant sur le déroulement du temps physique, RACK opère avec la même exactitude qu'il y ait de nombreux paquets en vol ou un seul segment résiduel.

Adaptation dynamique de la fenêtre de désordre et suivi de la variance du RTT

Pour prévenir les réactions inappropriées aux désordres momentanés, RACK met en œuvre une fenêtre dynamique ($\text{RACK.rwin}$). Si l'émetteur constate que le réseau inverse fréquemment les paquets, il élargit automatiquement cette marge temporelle pour laisser aux segments différés le temps d'arriver.

Le calcul de la fenêtre de base s'établit selon :

$$\text{RACK.rwin} = \max\left(\frac{\text{SRTT}}{4}, \text{Min_RTT_Window}\right)$$

Lorsqu'un bloc DSACK (Duplicate SACK, RFC 2883) confirme qu'un segment réexpédié avait en réalité déjà touché au but, RACK identifie une réémission prématurée causée par un désordre. En conséquence, l'algorithme majore $\text{RACK.rwin}$, immunisant les échanges ultérieurs contre les fausses alertes. Quand le parcours se stabilise, la fenêtre revient graduellement à son niveau initial.

[Arborescence décisionnelle de détection de perte RACK]
     ┌────────────────────────────────────────────────────────┐
     │          Arrivée d'un nouvel ACK ou d'un bloc SACK     │
     └───────────────────────────┬────────────────────────────┘
                                 │
                                 ▼
     ┌────────────────────────────────────────────────────────┐
     │     Mise à jour de RACK.rtt et du temps de livraison   │
     └───────────────────────────┬────────────────────────────┘
                                 │
                                 ▼
              Vérification : S.xmit_ts + RACK.rtt + RACK.rwin
                         <= Current_Time ?
                                ╱ ╲
                              ╱     ╲
                             OUI     NON
                            ╱         ╲
                           ▼           ▼
             ┌───────────────────┐   ┌───────────────────────┐
             │ Segment déclaré   │   │ Armer le délai RACK   │
             │ Réémission active │   │ Attendre la livraison │
             └───────────────────┘   └───────────────────────┘

Élimination des blocages de retransmission grâce au sondage de fin de flux (TLP)

Si RACK résout la détection des pertes lorsque des paquets ultérieurs fournissent des accusés de réception, il ne peut intervenir si le tout dernier paquet d'une séquence est écarté. Pour traiter ce cas sans subir la lenteur du RTO, la RFC 8985 intègre le mécanisme Tail Loss Probe (TLP).

Sondage préventif : transformer les délais RTO en reprise rapide Fast Recovery

Le mécanisme Tail Loss Probe introduit un temporisateur à intervalle court : le Probe Timeout (PTO). Lorsque l'application cesse de transmettre mais que des paquets restent non acquittés en ligne, le délai PTO s'écoule bien avant l'échéance du RTO.

À l'expiration du délai PTO, l'émetteur ne remet pas sa fenêtre de congestion à zéro et ne suppose pas une défaillance globale de la liaison. Il transmet simplement un segment sonde unique — des données en attente dans la mémoire tampon si disponibles, ou une réémission du segment au numéro de séquence le plus avancé.

Dès que le destinataire réceptionne cette sonde, il émet immédiatement un accusé dupliqué ou un bloc SACK. Cette réaction fournit à RACK une référence temporelle immédiate, lui permettant d'identifier la perte survenue plus tôt et d'enclencher la phase Fast Recovery sans rupture de débit.

Calculs du délai de temporisation PTO et critères de sélection du segment sonde

L'intervalle PTO est dimensionné pour intervenir juste après l'instant où un accusé classique aurait dû parvenir, avec une marge pour absorber la gigue :

$$\text{PTO} = \begin{cases} \max(2 \times \text{SRTT}, 10\text{ ms}) & \text{si segments en vol } = 1 \ \max(2 \times \text{SRTT}, 1.5 \times \text{SRTT} + \text{Wdelay}) & \text{si segments en vol } > 1 \end{cases}$$

Le facteur $\text{Wdelay}$ tient compte du retard d'acquittement toléré chez le récepteur (généralement plafonné à $200\text{ ms}$ ou annulé si SACK permet une confirmation immédiate).

En sollicitant proactivement une réponse du correspondant, TLP convertit les lourdes interruptions RTO en phases de reprise rapide et discrète.

Dynamique du niveau transport au sein des tunnels chiffrés VPN

L'encapsulation du trafic dans des tunnels sécurisés ajoute des en-têtes supplémentaires (IP, UDP, ESP, WireGuard), réduisant la taille maximale utile de segment (MSS) et élevant le risque de fragmentation. Par ailleurs, la traversée des réseaux opérateurs expose les paquets à des fluctuations de transit.

Atténuation des instabilités radio et des inversions de paquets en itinérance Wi-Fi

Sur les terminaux mobiles, le passage d'une borne Wi-Fi au réseau cellulaire génère de brefs ralentissements de file, amenant les paquets de l'ancienne interface à arriver après ceux de la nouvelle liaison.

Avec une pile TCP conventionnelle :

1. La transition réseau inverse l'ordre de deux paquets.
2. Le récepteur transmet deux DupACK.
3. Si un paquet intermédiaire a été véritablement perdu, la session se fige car le flux ne compte pas de troisième paquet pour générer le DupACK manquant.
4. L'application subit une interruption de 300 ms en attendant le RTO.

Sous le régime de la RFC 8985 :

1. RACK confronte l'instant d'arrivée à la fenêtre dynamique $\text{RACK.rwin}$, neutralisant l'alerte prématurée due à la transition radio.
2. Si le segment de queue a disparu, TLP expédie une sonde au bout de $2 \times \text{SRTT}$, guidant RACK pour rétablir la communication en quelques millisecondes.

Architecture du noyau : optimisation de la pile de transport avec RiceGuard

De nombreuses solutions logicielles traitent la pile réseau du système comme un composant immuable, laissant les flux chiffrés dépendre des réglages standards configurés pour les réseaux filaires de centres de données.

L'architecture VPNRice intègre le moteur RiceGuard, appliquant une optimisation fine des paramètres de transport sur les serveurs relais et les terminaux clients :

[Trafic applicatif interactif]
   (SSH / HTTP/2 / WebRTC / Jeux en ligne)
                     │
                     ▼  (Flux légers et intermittents)
[Module d'accélération RiceGuard]
   ├── Cœur RFC 8985 RACK-TLP (Détection des pertes par le temps)
   ├── Ajustement de la fenêtre de désordre (Protection anti-fausses alertes)
   ├── Ordonnancement adaptatif du PTO (Reprise des pertes en queue)
   └── Synchronisation de pacing avec BBRv3 et CUBIC
                     │
                     ▼  (Suppression des temps morts RTO)
[Tunnel de transport chiffré]
   (WireGuard / IPsec ESP / ChaCha20-Poly1305)

1. Généralisation de RACK-TLP : RiceGuard configure les connexions pour qu'elles s'appuient sur l'analyse temporelle, abolissant la dépendance envers la règle des trois DupACK.
2. Tolérance au désordre de routage : La coordination des métriques RACK internes avec le canal externe UDP prévient les baisses de régime intempestives induites par le routage multiparcours des opérateurs.
3. Pacing et préservation des sondes : L'émission des sondes de queue est synchronisée avec la régulation de débit FQ/CoDel, garantissant qu'elles ne soient pas éliminées par une congestion locale de mémoire tampon.

Audit et vérification diagnostique : supervision des sockets RACK et TLP

Les administrateurs système et ingénieurs réseau peuvent vérifier le statut et les réglages de la RFC 8985 RACK-TLP sous Linux via les commandes du noyau.

Examen de la configuration du mécanisme de recouvrement TCP :

# Consulter les paramètres en cours de détection de perte TCP
sysctl net.ipv4.tcp_recovery

# Masque de bits dans le noyau Linux :
# 0x1 : Activation de la détection RACK
# 0x2 : Activation du Tail Loss Probe (TLP)
# 0x4 : Activation de la fenêtre adaptative de réordonnancement
# Valeur recommandée : 0x7 (Tous composants actifs, par défaut depuis Linux 4.15+)

Pour activer pleinement l'ensemble des modules RACK-TLP, lancez la commande suivante :

# Validation complète de la pile RFC 8985 RACK-TLP
sudo sysctl -w net.ipv4.tcp_recovery=7

Afin d'examiner les connexions en cours et s'assurer de l'emploi effectif de la détection temporelle, utilisez l'utilitaire ss :

# Analyse des indicateurs internes TCP pour une session active
ss -ti dst 198.51.100.1

Recherchez la présence du terme rack dans les attributs de la connexion, ainsi que le paramètre reord, et les compteurs tlp et rto. Les sessions exploitant la RFC 8985 affichent un débit constant et un nombre quasi nul d'interruptions RTO lors des fluctuations de réseaux sans fil.

Télécharger VPNRice.