1. Introduction

Le principe de conservation des paquets (packet conservation principle) de Van Jacobson [Jacobson88] définit un processus d'auto-horloge dans lequel N segments de données livrés au récepteur génèrent des accusés de réception que l'expéditeur de données utilise comme horloge pour déclencher l'envoi de N autres segments de données dans le réseau.

Les algorithmes de contrôle de congestion comme Reno [RFC5681] et CUBIC [RFC9438] sont construits sur la base conceptuelle de ce processus d'auto-horloge. Ils contrôlent le processus d'envoi d'une connexion de protocole de transport en utilisant une fenêtre de congestion (congestion window, "cwnd") pour limiter "inflight", le volume de données qu'une connexion estime être en vol dans le réseau à un moment donné. De plus, ces algorithmes exigent que les connexions de protocole de transport réduisent leur cwnd en réponse aux pertes de paquets. La récupération rapide (fast recovery) (voir [RFC5681] et [RFC6675]) est l'algorithme permettant d'utiliser le retour d'information des accusés de réception pour effectuer cette réduction de cwnd. Son objectif déclaré est de maintenir l'auto-horloge de l'expéditeur en s'appuyant sur les ACK de retour pour synchroniser plus de données dans le réseau pendant la récupération.

Sans réduction proportionnelle du débit (Proportional Rate Reduction, PRR), la récupération rapide ajuste généralement la fenêtre en attendant la plupart d'un temps de trajet aller-retour (round-trip time, RTT) (la moitié d'un RTT d'ACK pour Reno [RFC5681], ou 30% d'un RTT pour CUBIC [RFC9438]) avant d'envoyer des données.

[RFC6675] rend la récupération rapide avec support d'accusé de réception sélectif (Selective Acknowledgment, SACK) [RFC2018] plus précise en calculant "pipe" (l'estimation de l'expéditeur du nombre d'octets encore en suspens dans le réseau). Avec [RFC6675], la récupération rapide est implémentée en envoyant des données selon les besoins à chaque ACK pour permettre à pipe de s'élever pour correspondre à ssthresh (la taille de fenêtre cible telle que définie par l'algorithme de contrôle de congestion pour la récupération rapide). Cela protège la récupération rapide contre les expirations de délai dans de nombreux cas où il y a une perte importante. Cependant, [RFC6675] présente deux lacunes notables.

Premièrement, parce qu'il effectue une très grande réduction multiplicative de cwnd au début de la récupération rapide, il peut provoquer une expiration de délai si les données ou les ACK de toute la seconde moitié de la fenêtre sont perdus. Deuxièmement, un seul ACK portant des options SACK qui impliquent une grande quantité de données manquantes peut provoquer une discontinuité par paliers dans l'estimateur de pipe, ce qui peut provoquer une rafale de données à transmettre lors de la retransmission rapide.

PRR régule le processus de transmission pendant la récupération rapide d'une manière qui évite ces ajustements excessifs de fenêtre de sorte que les transmissions se déroulent en douceur et, à la fin de la récupération, la taille réelle de la fenêtre sera aussi proche que possible de ssthresh.

L'approche adoptée par PRR a été inspirée par le principe de conservation des paquets de Van Jacobson. PRR s'appuie autant que possible sur le processus d'auto-horloge et n'est que faiblement affecté par la précision des estimateurs, tels que ceux pour la quantité de données en vol. C'est pourquoi l'algorithme maintient sa précision même en présence d'événements qui provoquent une incertitude pour d'autres estimateurs.

Lorsque inflight est au-dessus de ssthresh, PRR réduit progressivement inflight jusqu'à ssthresh en synchronisant les transmissions à un taux proportionnel aux données livrées et à ssthresh.

Lorsque inflight est en dessous de ssthresh, PRR sélectionne de manière adaptative entre deux limites de réduction (Reduction Bounds) pour limiter la réduction totale de fenêtre de tous les mécanismes (y compris les arrêts d'application transitoires et les pertes elles-mêmes). Comme référence, PRR utilise sa limite de réduction conservatrice (Conservative Reduction Bound, CRB) pour suivre strictement la conservation des paquets, par prudence lorsqu'il peut y avoir une congestion substantielle. Lorsque la récupération semble bien se dérouler, PRR utilise sa limite de réduction de démarrage lent (Slow Start Reduction Bound, SSRB), qui est plus agressive que PRR-CRB d'au plus un segment par ACK.

PRR-CRB satisfait la limite de conservation de paquets forte (Strong Packet Conservation Bound) décrite à l'annexe A ; cependant, ses performances dans les réseaux réels ne sont pas aussi bonnes que l'algorithme décrit dans [RFC6675], qui s'est avéré plus agressif dans un grand nombre de cas, lorsqu'il est utilisé comme algorithme unique. PRR-SSRB offre un compromis en permettant à une connexion d'envoyer un segment supplémentaire par ACK par rapport à PRR-CRB dans certaines situations. Bien que PRR-SSRB soit moins agressif que [RFC6675] (transmettant moins de segments ou prenant plus de temps pour les transmettre), il le surpasse en raison de la probabilité plus faible de pertes supplémentaires pendant la récupération.

La définition originale du principe de conservation des paquets [Jacobson88] traitait les paquets présumés perdus (par exemple, marqués comme candidats à la retransmission) comme ayant quitté le réseau. Cette idée se reflète dans l'estimateur inflight utilisé par PRR, mais elle diffère de la limite de conservation de paquets forte décrite à l'annexe A, qui est définie uniquement en fonction des données qui sont réellement arrivées au récepteur.

Ce document spécifie plusieurs changements majeurs par rapport à la version antérieure de PRR dans [RFC6937]. Premièrement, il introduit une nouvelle heuristique adaptative qui remplace un paramètre configuré manuellement qui déterminait à quel point PRR serait conservateur lorsque inflight est en dessous de ssthresh (s'il faut utiliser PRR-CRB ou PRR-SSRB).

Deuxièmement, l'algorithme spécifie le comportement pour les connexions non-SACK (connexions qui n'ont pas négocié le support SACK [RFC2018] via l'option "SACK-permitted"). Troisièmement, l'algorithme garantit un envoi fluide même dans les cas où un expéditeur subit un réordonnancement élevé et ne démarre la récupération de perte qu'après qu'un espace de séquence substantiel ait été SACKé.

Enfin, ce document inclut également une discussion supplémentaire sur l'intégration de PRR avec les algorithmes de contrôle de congestion et de détection de perte.

PRR possède une vaste expérience de déploiement dans plusieurs implémentations TCP depuis la première implémentation TCP PRR largement déployée en 2011 [First_TCP_PRR].