Résumé

  • PRR calcule à chaque ACK une quantité précise de données pouvant être émises, afin de rapprocher progressivement le volume en vol d’une cible fixée par l’algorithme de contrôle de congestion.
  • L’ACK atteste un progrès de livraison sur une surface étroite ; il ne prouve ni la guérison du chemin ni la justesse de la cible, d’où la nécessité de conserver les décisions et les mesures de chaque module.

Deux reprises, un même chiffre final

Imaginons vingt segments en vol et une perte qui conduit le contrôle de congestion à fixer la cible de reprise à dix. Une méthode peut abaisser brutalement la fenêtre, attendre que le volume estimé se vide, puis remettre plusieurs segments en circulation d’un coup. Dans l’exemple de la RFC 9937, cette attente devient une « demi-fenêtre de silence ».

Une autre méthode atteint dix en répartissant la réduction sur les ACK qui reviennent. La quantité totale envoyée peut être identique. La pression sur les files, le maintien de l’horloge d’acquittement et la lisibilité opérationnelle ne le sont pas.

C’est dans cet écart que s’inscrit Proportional Rate Reduction, ou PRR. L’article de 2011 signé par Nandita Dukkipati, Matt Mathis, Yuchung Cheng et Monia Ghobadi étudiait notamment les flux courts, les pauses applicatives, les pertes en rafale, les pertes ou réordonnancements d’ACK et les acquittements étirés. Les mécanismes antérieurs pouvaient réduire excessivement la fenêtre ou produire de fortes rafales. Pour les connexions touchées par des pertes dans cette étude, PRR et le travail associé sur la retransmission précoce réduisaient la latence TCP de 3 à 10 % selon la taille de la réponse.

Ce résultat reste attaché à son protocole de mesure.

La RFC expérimentale 6937 a suivi en 2013, avec Mathis, Dukkipati et Cheng. La RFC 9937, publiée sur la voie normative en décembre 2025 et signée par Mathis, Neal Cardwell, Cheng et Dukkipati, l’a remplacée. Cette continuité documentaire relie Dukkipati au problème de mesure, à l’expérience puis à la spécification révisée. Elle ne lui attribue ni une invention solitaire ni la maîtrise de toutes les implémentations.

La cible, le signal et l’autorisation

Le mécanisme devient beaucoup plus net lorsqu’on refuse de fondre trois responsabilités.

Le contrôle de congestion choisit d’abord ssthresh, la fenêtre visée à la fin de l’épisode. Reno, CUBIC ou un autre contrôleur compatible porte cette décision. PRR ne diagnostique pas seul la gravité de la congestion et ne fixe pas la cible.

La machine de reprise observe ensuite les ACK. DeliveredData désigne la meilleure estimation, côté émetteur, du nombre d’octets que l’ACK courant indique comme livrés depuis l’ACK précédent. Il s’agit d’une observation utile, mais située. Elle ne dit pas tout du trajet aller, du trajet retour, des pertes restantes ni de l’application.

PRR calcule enfin SndCnt, la quantité exacte qu’il est permis d’émettre en réponse. Une fonction distincte choisit s’il faut retransmettre des données manquantes ou envoyer des données nouvelles. PRR règle le volume et le rythme ; il ne choisit pas le contenu.

Cette architecture est mince sans être vague. La règle partagée est déterministe. Les décisions qui exigent d’autres informations demeurent locales aux composants qui les possèdent. Un ACK n’obtient aucun mandat général parce qu’il est arrivé au bon moment.

Faire du progrès une cadence

Au début de la reprise, l’émetteur mémorise RecoverFS, son estimation du volume initial susceptible d’être livré pendant l’épisode. Il cumule ensuite ce qui a été livré dans prr_delivered et ce qui a été émis dans prr_out.

Tant que le volume en vol dépasse ssthresh, le calcul proportionnel détermine ce qui aurait dû être libéré compte tenu du progrès observé et de la cible réduite. Il arrondit l’autorisation, retranche ce qui est déjà parti et produit le prochain SndCnt.

L’ACK fonctionne donc comme un reçu qui ouvre un crédit limité. Un petit progrès ouvre une petite émission. Si des ACK se perdent, un acquittement ultérieur peut regrouper davantage de progrès ; le calcul se remet à niveau sans transformer automatiquement une rupture d’estimation en rafale sans borne.

Il ne faut pas lui faire dire davantage. Le reçu indique que des octets ont avancé. Il ne révèle pas à lui seul pourquoi ils avaient été perdus, si le goulot a disparu ou si la valeur de ssthresh était judicieuse. La cible reste sous la responsabilité du contrôle de congestion.

Quand le volume passe sous la cible

Des pertes nombreuses peuvent faire descendre l’estimation du volume en vol sous ssthresh. Rester strictement conservateur peut ralentir la reprise ; accélérer sans preuve peut déclencher de nouvelles pertes. La RFC 9937 articule alors deux bornes.

La Conservative Reduction Bound constitue le choix par défaut et reste étroitement liée aux données livrées. La Slow Start Reduction Bound peut ajouter au plus un segment maximal de l’émetteur lorsqu’un SafeACK fait avancer l’acquittement cumulatif sans signaler une nouvelle perte.

La révision de 2025 a rendu cette sélection adaptative après l’étude de limiteurs à seau de jetons. Une fois leurs jetons épuisés, certains équipements peuvent rejeter brutalement une grande part du trafic sans avoir révélé leur rythme de recharge. La cible déduite de performances antérieures devient alors trop optimiste. La prudence précède donc l’accélération ; l’octet supplémentaire doit être justifié par le progrès défini.

Le nom SafeACK ne vaut pas certificat de sûreté. Il signifie seulement que l’ACK courant satisfait les conditions étroites autorisant cette variante du calcul.

Une fin explicite, pas une absolution

Chaque émission augmente prr_out. À la fin, PRR place cwnd sur ssthresh. Pourtant, la RFC 9937 signale que cette étape peut encore autoriser une rafale de segments consécutifs dans certains cas et recommande le pacing pour en limiter la brutalité.

La spécification n’efface donc pas tout risque temporel. Elle ne transforme pas non plus les effets possibles d’un « pacing doux » en bénéfices universellement quantifiés. Elle définit un algorithme, ses interfaces et ses limites.

La RFC relève que PRR sert depuis 2011 d’algorithme de reprise rapide dans Linux TCP pour les modules de contrôle de congestion par défaut et pris en charge. C’est une histoire d’implémentation importante, pas la preuve qu’un noyau donné a choisi hier la bonne branche, activé le pacing ou obtenu le gain de latence de l’étude initiale.

Ce que doit contenir le reçu d’exploitation

Une affirmation vérifiable commence par identifier la version du transport et du contrôleur, le déclencheur de détection de perte, les valeurs initiales de cwnd, inflight et RecoverFS, ainsi que le composant ayant choisi ssthresh.

Pour chaque ACK utile, il faut conserver le progrès cumulatif, les pertes nouvellement signalées, DeliveredData, le résultat et la raison de SafeACK, la branche proportionnelle, CRB ou SSRB, le SndCnt calculé, les octets réellement envoyés et le nouveau prr_out. La décision séparée entre retransmission et données nouvelles doit rester visible.

À la sortie, le dossier doit montrer la fenêtre finale, le volume en vol, l’état du pacing, toute rafale, tout timeout ou nouvelle perte, puis les distributions de latence et de débit face à une cohorte comparable. Les essais doivent couvrir réordonnancement, pause applicative, cas SACK et non-SACK lorsque disponibles, ainsi que limitation par seau de jetons. Il faut aussi conserver les contre-exemples où les ACK progressent alors que le chemin ou l’application reste dégradé.

On obtient ainsi une hiérarchie de faits. L’ACK observe une livraison. Le contrôleur choisit une cible. PRR calcule un crédit. Un autre composant sélectionne les octets. Le code les émet. Seules les mesures établissent l’effet.

Sources