5. Relations avec d'autres normes (Relationships to Other Standards)
PRR peut être utilisé avec n'importe quel algorithme de contrôle de congestion qui a l'intention d'appliquer une réduction multiplicative à son taux d'envoi sur une échelle de temps d'environ un temps d'aller-retour, où la quantité actuelle de données en vol est limitée par la fenêtre de congestion (cwnd), et où la quantité cible de données en vol pendant cette réduction est une valeur fixe donnée par ssthresh.
En particulier, PRR est adapté pour une utilisation avec les algorithmes de contrôle de congestion Reno [RFC5681] et CUBIC [RFC9438].
Relation avec les algorithmes de récupération de perte
PRR est décrit comme une modification de « L'algorithme conservateur de récupération de perte pour TCP basé sur SACK » [RFC6675]. Il est plus précis lorsqu'il est utilisé avec SACK [RFC2018], mais SACK n'est pas requis.
PRR peut être combiné avec une large gamme d'algorithmes de détection de perte. Ceci parce que PRR ne dépend pas des détails de la façon dont l'algorithme de détection de perte estime quels paquets ont été livrés et quels paquets ont été perdus. À la réception de chaque ACK, PRR a seulement besoin que l'algorithme de détection de perte communique combien de paquets ont été marqués comme perdus et combien de paquets ont été marqués comme livrés.
Par conséquent, PRR peut être combiné avec les algorithmes de détection de perte spécifiés ou décrits dans les documents suivants :
- Reno [RFC5681]
- NewReno [RFC6582]
- SACK [RFC6675]
- Forward Acknowledgment (FACK) [FACK]
- Recent Acknowledgment Tail Loss Probe (RACK-TLP) [RFC8985]
En raison des caractéristiques de performance de RACK-TLP, incluant la résilience à la perte de queue, au réordonnancement et aux retransmissions perdues, il est RECOMMANDÉ que PRR soit implémenté avec la récupération de perte RACK-TLP [RFC8985].
Origine de l'heuristique SafeACK
L'heuristique SafeACK était une conséquence du développement d'une détection robuste de retransmission perdue dans un précurseur précoce de [RFC8985].
Sans détection de retransmission perdue, les policers causant des taux de perte de paquets très élevés faisaient face à un risque extrêmement élevé de provoquer des délais d'expiration de retransmission, car Reno [RFC5681], CUBIC [RFC9438] et [RFC6675] pouvaient envoyer des retransmissions bien au-dessus du taux de policing.
Compatibilité avec les algorithmes de contrôle de congestion
PRR est conçu pour bien fonctionner avec divers algorithmes de contrôle de congestion :
Contrôle de congestion Reno
- PRR lisse le processus de récupération rapide de Reno
- Évite la réduction brutale de fenêtre de Reno au début de la récupération
- Fournit un taux d'envoi plus stable
Contrôle de congestion CUBIC
- PRR est compatible avec le mécanisme de réduction de fenêtre de CUBIC
- Fournit un contrôle de taux précis pendant la récupération rapide
- Maintient les caractéristiques de croissance de CUBIC après la récupération
Compatibilité ECN
PRR peut être adapté pour une utilisation avec la notification explicite de congestion (ECN) [RFC3168] en utilisant des portions de la machine à états de récupération de perte pour invoquer le traitement PRR en réponse au marquage ECN plutôt qu'à une perte réelle de paquet.
Compatibilité avec les protocoles de transport
Bien que PRR ait été initialement conçu pour TCP, ses principes de base peuvent être appliqués à d'autres protocoles de transport, à condition qu'ils :
- Utilisent un contrôle de congestion basé sur fenêtre
- Aient un mécanisme similaire à la récupération rapide
- Puissent estimer la quantité de données en vol
- Reçoivent des accusés de réception pour les données envoyées
Le chapitre 9 discute en détail les considérations pour adapter PRR à d'autres protocoles de transport.