TCP PRR RFC 6937 : reprise sur perte, régulation du FlightSize et latence VPN

Les liaisons chiffrées à haut débit et les réseaux privés virtuels professionnels s'appuient massivement sur le protocole TCP pour assurer l'acheminement intègre des flux. Lorsque les paquets franchissent de multiples routeurs intermédiaires, des relais cellulaires ou des réseaux Wi-Fi sujets aux interférences, des pertes ponctuelles surviennent inévitablement. La façon dont la couche de transport réagit à ces pertes détermine si l'application subit une micro-pause imperceptible ou un gel total du débit associé à des pics de latence dus au phénomène de bufferbloat.

Pendant près de deux décennies, la gestion de congestion standard s'est appuyée sur les mécanismes classiques de reprise rapide (Fast Recovery) formalisés dans les RFC 3517 et RFC 5681. Ces algorithmes souffraient d'un défaut structurel : dès la détection d'une perte, ils imposaient un silence d'émission complet suivi d'une salve violente de paquets, provoquant des ruptures d'écoulement préjudiciables. Normalisé dans la RFC 6937 de l'IETF, l'algorithme Proportional Rate Reduction (PRR) refonde la reprise sur perte en cadençant continuellement l'émission des paquets à un rythme proportionnel, supprimant les arrêts artificiels et stabilisant le transport.

Le dilemme de la bulle de transmission : comment la reprise rapide classique fige TCP

Dans le modèle de contrôle classique, la réception de trois acquittements dupliqués (Duplicate ACK) indique que le lien ne peut plus absorber la fenêtre de congestion (CWND) actuelle. Le protocole divise alors CWND par deux pour définir un nouveau seuil de démarrage lent (ssthresh). Si la baisse du débit est nécessaire pour désengorger les files d'attente intermédiaires, la méthode d'application historique provoquait des effets secondaires néfastes.

Conformément à la RFC 3517, l'émetteur comptabilise le volume de données en vol non acquittées (FlightSize). Lors d'une perte, la valeur de FlightSize excède largement le nouveau seuil réduit ssthresh :

Événement de perte détecté :
  État initial : CWND = 40 paquets, FlightSize = 40 paquets
  État cible   : ssthresh = 20 paquets

Comportement de la reprise classique :
  Arrêt complet d'émission jusqu'à ce que FlightSize chute de 40 à 20.
  Durée du silence : Environ la moitié d'un temps d'aller-retour (0.5 * RTT).

Cette interruption contrainte génère une « bulle de transmission » (pipeline bubble). Durant un demi-RTT, l'émetteur n'envoie strictement aucun paquet. La file d'attente du goulot d'étranglement se vide complètement. Lorsque FlightSize atteint enfin ssthresh, l'émetteur reprend soudainement son activité en injectant une rafale de paquets consécutifs dans la liaison libérée. Cette salve sature à nouveau les mémoires tampons, provoquant de nouvelles pertes secondaires et menant à des expirations de temporisation (RTO). Dans un tunnel VPN, ces à-coups se traduisent par des gels vidéo et des sauts de ping de plusieurs centaines de millisecondes.

Anatomie mathématique de la RFC 6937 : mécanique de la réduction proportionnelle de débit

La RFC 6937 remplace les périodes de blocage par un lissage proportionnel continu. Au lieu d'attendre passivement que FlightSize diminue, l'algorithme PRR émet de nouveaux segments à chaque acquittement sélectif (SACK) reçu, ajustant progressivement le rythme pour converger en douceur vers ssthresh sur toute la durée de la reprise.

L'algorithme maintient deux compteurs d'état essentiels :

• prr_delivered : Volume total de données confirmées comme livrées par les blocs SACK depuis l'entrée en reprise.
• prr_out : Volume total de données nouvelles ou retransmises émises sur le réseau depuis la détection de la perte.

L'automate PRR détermine la quantité exacte d'octets autorisés à l'émission pour chaque ACK selon une formule proportionnelle :

Target_Ratio = ssthresh / RecoverFS
sndcnt = ceil(prr_delivered * Target_Ratio) - prr_out

Dans cette relation, RecoverFS représente la valeur de FlightSize au moment précis de la perte. Si ssthresh correspond à la moitié de RecoverFS, le ratio cible s'établit à Target_Ratio = 0.5. Dès lors, pour chaque bloc de 2 octets validé par le destinataire, l'émetteur transmet immédiatement 1 octet de données. L'acheminement ne s'interrompt jamais, les tampons se vident à une cadence prévisible et la liaison demeure alimentée de manière homogène.

Dynamique des frontières : comparaison des modes opérationnels PRR-CRB et PRR-SSRB

Bien que la formule proportionnelle idéale convienne parfaitement aux conditions habituelles, les réseaux réels subissent des arrivées d'ACK irrégulières, des pertes de retransmissions et des inversions d'ordre de paquets. Afin de garantir une stabilité sans faille, la RFC 6937 définit deux modes frontières complémentaires : la borne de débit conservatrice (CRB) et la borne de démarrage lent (SSRB).

+-------------------------------------------------------------+
|                 Traitement de l'ACK dans la pile            |
+-------------------------------------------------------------+
                               |
                               v
             [Vérification : FlightSize > ssthresh ?]
                /                                      OUI                      NON
              /                                        v                             v
+---------------------------+  +------------------------------+
|     Mode PRR ou CRB       |  |          Mode PRR-SSRB       |
| sndcnt = min(PRR, Deliv)  |  | sndcnt = min(Deliv+1, Target)|
+---------------------------+  +------------------------------+

Borne de débit conservatrice (CRB) pour les scénarios de pertes massives et de désordonnancement

En cas de pertes sévères ou d'acheminement retardé des ACK, FlightSize peut demeurer durablement supérieur à ssthresh. Dans cette situation, une émission soutenue aggraverait l'engorgement. Le mode PRR-CRB intervient alors comme un garde-fou :

sndcnt = min(sndcnt, Delivered_Data)

PRR-CRB impose que le volume émis ne dépasse jamais la quantité de données explicitement reconnue comme livrée dans l'ACK courant. En calquant l'envoi sur la libération réelle de la bande passante, le mode CRB empêche la formation de files d'attente artificielles et résiste aux anomalies d'inversion d'ordre.

Borne de réduction en démarrage lent (SSRB) pour les flux interactifs sensibles à la latence

À l'inverse des pertes massives, des pertes brèves peuvent faire chuter FlightSize nettement en dessous du seuil ssthresh (par exemple lors de pertes groupées ou de transitions sans fil). Dans le TCP traditionnel, un FlightSize trop faible imposait un sondage paquet par paquet particulièrement lent.

Le mode PRR-SSRB détecte la condition FlightSize < ssthresh et autorise une accélération modérée :

sndcnt = min(prr_delivered - prr_out + ssthresh - FlightSize, Max_Burst)

Le mode SSRB permet d'émettre jusqu'à deux paquets pour chaque paquet validé, rétablissant prestement FlightSize au niveau de ssthresh sans provoquer d'onde de choc. Ce comportement se montre précieux pour les sessions SSH, la visioconférence et les jeux vidéo transitant par VPN.

Synchronisation FlightSize et CWND : élimination des rafales et des pertes en fin de fenêtre

Les approches classiques ajustaient fréquemment CWND de façon brute pendant le traitement des incidents, ce qui déclenchait une libération massive de paquets en sortie de reprise. La RFC 6937 dissocie le calcul de quota sndcnt de la gestion de la variable interne CWND :

Grâce à cet alignement permanent, FlightSize correspond rigoureusement à ssthresh au terme de la phase de reprise. La liaison réintègre l'évitement de congestion sans à-coup, supprimant le risque de pertes de fin de fenêtre.

Interaction entre SACK, FACK et PRR dans les piles réseau Linux modernes

Dans le noyau Linux, PRR constitue le moteur d'exécution de référence sous tous les algorithmes de congestion. La RFC 6937 exploite les acquittements sélectifs (SACK, RFC 2018 / RFC 6675) pour évaluer précisément le volume de données ayant quitté la liaison à chaque retour.

Couplé à FACK (Forward Acknowledgment), le noyau dresse une cartographie fidèle des discontinuités dans l'espace de numérotation, distinguant les pertes isolées des incidents généralisés. PRR déduit prr_delivered des blocs contigus confirmés et guide le planificateur Fair Queuing (sch_fq) avec une précision temporelle remarquable.

Pièges d'encapsulation : comportement de PRR dans les tunnels WireGuard et IPsec

L'intégration de PRR au sein des architectures VPN met en jeu des interactions notables entre le flux applicatif interne et l'enveloppe de transport externe. Sous WireGuard, IPsec ou OpenVPN, les segments TCP d'origine sont encapsulés dans des datagrammes UDP ou des en-têtes ESP.

Fragmentation du MTU externe et amplification des pertes éphémères

Si le mécanisme de découverte du MTU (PMTUD) est altéré ou si le réseau limite la taille des paquets sous 1500 octets, les segments TCP internes peuvent provoquer la fragmentation des paquets IP externes. La perte d'un seul fragment externe entraîne alors l'échec de tout le paquet TCP intérieur :

• Une perte de 2 % de fragments externes peut se répercuter en une perte apparente de 4 % à 8 % au niveau TCP.
• Les anciens algorithmes s'effondrent rapidement dans une suite de temporisations RTO.
• PRR atténue ce risque en préservant un flux modéré et régulier, évitant le débordement des passerelles VPN.

Interaction avec les moteurs de contrôle de congestion BBR, CUBIC et Reno

PRR s'intègre harmonieusement sous les principaux gestionnaires de transport :

• CUBIC : Le noyau Linux associe nativement CUBIC à PRR. Lorsque CUBIC réduit sa fenêtre de 30 % en présence de pertes ($eta = 0.7$), PRR applique un Target_Ratio = 0.7 garantissant une transition sans secousse.
• BBR : Bien que BBR établisse un modèle direct de bande passante, ses déclinaisons intègrent les principes de lissage de PRR lors des phases de purge pour prévenir la pression sur les tampons.
• Reno : Associé au schéma Reno historique, PRR permet une réduction de moitié du débit sans les blocages caractéristiques du modèle originel.

Métriques comparatives : distribution de la latence et efficacité de vidage des files d'attente

Des essais en conditions de production illustrent les bénéfices tangibles de PRR par rapport aux mécanismes traditionnels :

En préservant l'horloge des paquets, PRR élimine l'assèchement de la liaison qui altérait jadis les performances des tunnels chiffrés.

Architecture de lissage RiceGuard : transport multi-chemins à faible gigue

VPNRice intègre les principes de PRR au cœur de sa structure d'acheminement RiceGuard. Les passerelles de bordure RiceGuard soutiennent des milliers de connexions chiffrées concurrentes via une infrastructure Anycast distribuée.

Afin d'assurer une stabilité exemplaire pour le jeu en réseau, le streaming et les bureaux distants, RiceGuard optimise la reprise à plusieurs niveaux :

1. Régulation PRR au niveau du noyau : Chaque passerelle RiceGuard fonctionne sous un noyau Linux configuré avec PRR et Fair Queuing (fq), garantissant que des pertes côté client ne bloquent pas le réseau dorsal.
2. Gestion fine du MTU et serrage MSS : Le système applique un serrage MSS automatique aux interfaces de tunnels, neutralisant les fragmentations externes préjudiciables aux calculs d'octets livrés.
3. Maintien continu de l'horloge d'acquittement : En conservant un rythme d'émission proportionnel durant les pertes, RiceGuard élimine les micro-gels récurrents propres aux VPN ordinaires.

Cette architecture veille à ce que des perturbations ponctuelles sur les réseaux mobiles ou les points d'accès Wi-Fi publics ne dégradent pas la qualité de service globale.

Guide d'optimisation en production : paramètres du noyau et tampons de tunnels

Les administrateurs système peuvent valider et affiner le comportement de PRR sur leurs serveurs VPN Linux à l'aide des paramètres usuels :

• Vérification du support PRR : S'assurer que le noyau prend en charge PRR (actif par défaut dès Linux 3.2). Contrôler /proc/sys/net/ipv4/tcp_congestion_control et vérifier l'activation de SACK (net.ipv4.tcp_sack = 1).
• Activation de Fair Queuing : Déployer le module FQ pour assurer un cadençage matériel à l'échelle du paquet : sysctl -w net.core.default_qdisc = fq.
• Ajustement du MTU et clamp MSS : Mettre en œuvre le serrage MSS sur les interfaces virtuelles (iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu) afin d'écarter la fragmentation externe.
• Observation des compteurs de reprise : Surveiller les indicateurs TCP en temps réel via nstat -az TcpPrr* et ss -tie pour analyser le comportement de prr_delivered et prr_out.
• Limitation du bufferbloat : Calibrer la taille maximale du tampon d'écriture des sockets (net.ipv4.tcp_wmem) pour prévenir l'accumulation excessive de données en vol avant toute saturation.