9. Adaptation de PRR à d'autres protocoles de transport
L'algorithme PRR principal et les limites de réduction peuvent être adaptés à tout protocole de transport capable de prendre en charge [RFC6675]. Dans une implémentation majeure (Linux TCP), PRR est l'algorithme de récupération rapide pour ses modules de contrôle de congestion par défaut et pris en charge depuis son introduction en 2011 [First_TCP_PRR].
L'heuristique SafeACK peut être généralisée à tout ACK pour une retransmission qui ne provoque pas le marquage d'un autre segment pour retransmission.
10. Études de mesure (Measurement Studies)
Pour [RFC6937], un article compagnon [IMC11] a évalué [RFC3517] et diverses versions expérimentales de PRR dans des études de mesure à grande échelle. Au moment de la publication, les algorithmes hérités utilisés dans l'étude n'existaient plus dans les bases de code utilisées pour l'étude, rendant de telles comparaisons difficiles sans recréer les algorithmes historiques.
Les lecteurs intéressés par les études de mesure devraient consulter la section 5 de [RFC6937] et l'article IMC [IMC11].
11. Considérations opérationnelles (Operational Considerations)
11.1. Déploiement incrémental (Incremental Deployment)
PRR est déployable de manière incrémentale car il n'exploite que les mécanismes de protocole de transport existants pour accuser réception de la livraison de données et détecter les données perdues.
Exigences de déploiement :
- PRR ne nécessite que des modifications de l'implémentation du protocole de transport de l'émetteur de données
- Aucune modification n'est nécessaire pour le récepteur de données
- Aucune modification n'est nécessaire pour le réseau
Cela permet aux émetteurs de données utilisant PRR de fonctionner correctement avec n'importe quel récepteur de données ou réseau existant. PRR ne nécessite aucune modification ou assistance des routeurs, commutateurs ou autres appareils du réseau.
11.2. Équité (Fairness)
PRR vise à maintenir les propriétés d'équité de l'algorithme de contrôle de congestion avec lequel il est déployé.
Comment ça fonctionne :
- PRR ne s'exécute que pendant une phase de réponse de contrôle de congestion (telle que la récupération rapide ou une réduction par étapes de cwnd d'une réaction TCP ECN définie dans [RFC3168])
- Ne prend que des décisions à court terme, par accusé de réception, pour réguler en douceur la quantité de données en vol pendant la phase de régulation
- De sorte qu'à la fin de la phase, elle s'approche aussi près que possible du seuil de démarrage lent (ssthresh) déterminé par l'algorithme de contrôle de congestion
Mécanismes non modifiés :
- PRR ne modifie pas les mécanismes d'augmentation ou de diminution de cwnd du contrôle de congestion en dehors des phases de réponse de contrôle de congestion
11.3. Protection du réseau contre la mise en file d'attente excessive et la perte de paquets
Impact à long terme
Sur des échelles de temps longues, PRR vise à maintenir les propriétés de mise en file d'attente et de perte de paquets de l'algorithme de contrôle de congestion avec lequel il est déployé.
Comme décrit ci-dessus, PRR ne s'exécute que pendant une phase de réponse de contrôle de congestion (telle que la récupération rapide ou la réponse à ECN), et ne prend que des décisions à court terme, par accusé de réception, pour réguler en douceur la quantité de données en vol pendant la phase de régulation, de sorte qu'à la fin de la phase, elle s'approche aussi près que possible du seuil de démarrage lent (ssthresh) déterminé par l'algorithme de contrôle de congestion.
Impact à court terme
Sur des échelles de temps courtes, PRR vise à entraîner des taux de perte de paquets inférieurs à ceux des approches précédentes comme [RFC6675].
Principe d'avantage :
- PRR est inspiré par le principe de conservation des paquets
- S'appuie sur des processus auto-cadencés dans la mesure du possible
- Avec [RFC6675], un seul ACK portant des options SACK et impliquant une grande quantité de données manquantes peut provoquer une discontinuité par étapes dans l'estimateur de pipe
- Cela peut entraîner une retransmission rapide envoyant une grande rafale de données dépassant largement la quantité de données livrées
- PRR évite de telles rafales en prenant des décisions de transmission basées sur la quantité de données livrées plutôt que sur la quantité de données perdues
Amélioration des performances :
- Comme décrit ci-dessus, PRR-SSRB est moins agressif que [RFC6675] (transmettant moins de segments ou prenant plus de temps pour les transmettre)
- En raison d'une probabilité plus faible de perte de paquets supplémentaire pendant la récupération, il surpasse ce dernier
12. Considérations IANA (IANA Considerations)
Ce document n'a pas d'actions IANA.
13. Considérations de sécurité (Security Considerations)
PRR ne modifie pas le profil de risque du protocole de transport.
Protection contre les attaques par division d'ACK :
Les implémenteurs adaptant PRR du comptage d'octets au comptage de segments doivent faire attention à l'impact des attaques par division d'ACK [Savage99], où les récepteurs accusent réception de segments partiels dans l'intention de confondre la comptabilité de congestion de l'émetteur.
Recommandation : Utiliser le comptage d'octets plutôt que le comptage de segments défend mieux contre de telles attaques.