7. Propriétés (Properties)

Les propriétés suivantes sont communes à PRR-CRB et PRR-SSRB, sauf indication contraire :

1. Maintien de l'horloge ACK

PRR tente de maintenir l'horloge ACK de l'expéditeur à travers les événements de récupération, y compris les pertes en rafale. En revanche, [RFC6675] peut (peut) envoyer de grandes rafales non synchronisées après des pertes en rafale.

Avantage : Évite d'introduire du trafic supplémentaire en rafale dans le réseau, aidant à stabiliser le contrôle de congestion.

2. Réduction de fenêtre fluide

Normalement, PRR répartit les réductions de fenêtre volontaires de manière uniforme sur un RTT complet. Cela a le potentiel de réduire généralement le caractère en rafale du trafic Internet et peut (peut) être considéré comme une forme de pacing doux.

Hypothétiquement, tout pacing augmente la probabilité que différents flux soient entrelacés, réduisant l'opportunité de compression des ACK et d'autres phénomènes qui augmentent le caractère en rafale du trafic. Cependant, ces effets n'ont pas été quantifiés.

3. Convergence précise vers la fenêtre cible

S'il y a des pertes minimales, PRR convergera précisément vers la fenêtre cible choisie par l'algorithme de contrôle de congestion. Notez que lorsque l'expéditeur approche de la fin de la récupération, prr_delivered approchera de RecoverFS, et SndCnt sera calculé de sorte que prr_out approche de ssthresh.

Garantie mathématique : Dans des conditions idéales, inflight = ssthresh à la fin de la récupération.

4. Adaptation automatique aux réductions de fenêtre implicites

Les réductions de fenêtre implicites, dues à de multiples pertes isolées pendant la récupération, provoquent le saut des réductions volontaires ultérieures. Pour un petit nombre de pertes, la taille de la fenêtre se termine précisément à la fenêtre choisie par l'algorithme de contrôle de congestion.

Mécanisme : PRR s'ajuste automatiquement pour que la somme des pertes réelles et des réductions volontaires atteigne la réduction cible.

5. Gestion des pertes en rafale

Pour les pertes en rafale, les réductions de fenêtre volontaires antérieures peuvent (peut) être annulées en envoyant des segments supplémentaires en réponse aux ACK arrivant plus tard pendant la récupération. Notez que tant que certaines réductions de fenêtre volontaires ne sont pas annulées et qu'il n'y a pas d'arrêt d'application, la valeur finale d'inflight sera la même que ssthresh.

Flexibilité : Permet d'être plus conservateur lorsque une congestion sévère est détectée, et plus agressif lorsque les conditions s'améliorent.

6. Gestion des arrêts d'application

PRR avec l'une ou l'autre limite de réduction améliore la situation lorsqu'il y a un arrêt d'application, par exemple, lorsque l'application émettrice ne met pas en file d'attente les données pour la transmission assez rapidement ou que le récepteur arrête d'avancer sa fenêtre de réception.

Gestion des scénarios d'arrêt

Lorsqu'un arrêt d'application se produit tôt pendant la récupération :

• prr_out prendra du retard sur la somme des transmissions permises par SndCnt
• Les opportunités de transmission manquées en raison des arrêts sont traitées comme des réductions de fenêtre volontaires mises en banque
• Plus précisément, elles font que prr_delivered - prr_out soit significativement positif

Mécanisme de rattrapage

Si l'application rattrape pendant que l'expéditeur est encore en récupération :

• L'expéditeur enverra une rafale de fenêtre partielle pour augmenter inflight
• Cela fait qu'inflight approche de la position exacte qu'il aurait eue si l'application ne s'était jamais arrêtée
• Bien qu'une telle rafale puisse (peut) être préjudiciable au flux donné ou à d'autres flux partageant le chemin, c'est exactement ce qui se passe pour les arrêts d'application RTT partiels chaque fois qu'il n'est pas en récupération

Comportement unifié : PRR rend le comportement d'arrêt RTT partiel uniforme dans tous les états. Changer ce comportement est hors de portée de ce document.

7. Robustesse aux erreurs de l'estimateur inflight

PRR avec limites de réduction est moins sensible aux erreurs dans l'estimateur inflight.

Pendant la récupération, inflight est fondamentalement un estimateur qui utilise des informations incomplètes pour estimer si les segments non SACKés sont réellement perdus ou simplement en désordre dans le réseau. Dans certaines conditions, inflight peut (peut) avoir des erreurs significatives ; par exemple, lorsqu'une rafale de données réordonnées est prématurément supposée perdue et marquée pour retransmission, inflight est sous-estimé.

Mécanisme de tolérance aux erreurs

Si les transmissions sont régulées directement par inflight (comme dans [RFC6675]) :

• Une discontinuité par paliers dans l'estimateur inflight provoque une rafale de données
• La rafale ne peut (peut) pas être rétractée une fois que l'estimateur inflight est corrigé quelques ACK plus tard

Avec la dynamique PRR :

• inflight détermine uniquement quel algorithme (PRR ou limite de réduction) est utilisé pour calculer SndCnt à partir de DeliveredData
• Lorsque inflight est sous-estimé, les algorithmes diffèrent d'au plus 1 segment par ACK
• Une fois qu'inflight est mis à jour, ils convergent vers la même fenêtre finale à la fin de la récupération

8. Limite de conservation de paquets forte (PRR-CRB)

Dans toutes les conditions et séquences d'événements pendant la récupération, PRR-CRB limite strictement les données transmises pour être égales ou inférieures à la quantité de données livrées au récepteur. Cette limite de conservation de paquets forte est l'algorithme le plus agressif qui ne conduit pas à des pertes forcées supplémentaires dans certains environnements.

Propriété de longueur de file d'attente

Il a la propriété que s'il y a une file d'attente permanente à un goulot d'étranglement sans trafic croisé, la file d'attente maintiendra une longueur complètement constante pendant la récupération, à l'exception des fluctuations +1/-1 dues aux différences de temps d'arrivée et de départ des paquets.

Voir l'annexe A pour une discussion détaillée de cette propriété.

9. Compromis PRR-SSRB

Bien que la limite de conservation de paquets forte soit très attrayante pour plusieurs raisons, des mesures antérieures (discutées dans la section 6 de [RFC6675]) suggèrent qu'elle n'est pas assez agressive et ne performe pas aussi bien que l'algorithme décrit dans [RFC6675], qui permet des rafales de données en présence de pertes en rafale.

PRR-SSRB est un compromis qui permet à une connexion d'envoyer 1 segment supplémentaire par ACK par rapport à la limite de conservation de paquets lorsque l'ACK indique que la récupération progresse bien sans pertes supplémentaires.

Équilibre de performance

Du point de vue de la limite stricte de conservation de paquets :

• PRR-SSRB ouvre effectivement la fenêtre pendant la récupération
• Mais il est beaucoup moins agressif que [RFC6675] en présence de pertes en rafale
• Il surpasse ce dernier en raison de la probabilité plus faible de pertes supplémentaires pendant la récupération

Effet pratique : PRR-SSRB offre une meilleure stabilité que [RFC6675] tout en maintenant de bonnes performances.