Aller au contenu principal

8. Exemples (Examples)

Cette section illustre le comportement des algorithmes PRR et [RFC6675] en montrant comment ils diffèrent dans leur réponse à deux scénarios d'exemple : une connexion subissant la perte d'un seul paquet ou une rafale de 15 paquets consécutifs perdus.

Configuration du scénario de test​

Tous les cas utilisent :

  • Transfert de données en masse (pas de pause d'application)
  • Contrôle de congestion Reno [RFC5681]
  • État initial : cwnd = FlightSize = inflight = 20 segments
  • ssthresh : Sera défini à 10 au début de la récupération
  • Retransmission rapide : Utilise la retransmission rapide standard [RFC5681]
  • Limited Transmit [RFC3042] : Envoie 2 nouveaux segments + 1 retransmission en réponse aux trois premiers ACK dupliqués

Explication du diagramme​

Les diagrammes suivants montrent la réponse par ACK pour le premier aller-retour après la perte du segment 0. La ligne supérieure (« ack# ») indique le numéro de segment qui a déclenché l'ACK, avec X indiquant les segments perdus.

Les lignes « cwnd » et « inflight » montrent les valeurs de cwnd et inflight de ces algorithmes après le traitement de chaque ACK de retour mais avant toute (re)transmission supplémentaire. La ligne « sent » indique combien de « N » nouvelles données ou « R » retransmissions seront envoyées.

Exemple 1 : Perte d'un seul segment​

RFC 6675
a  X  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22
c 20 20 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
i 19 19 18 18 17 16 15 14 13 12 11 10  9  9  9  9  9  9  9  9  9  9
s  N  N  R  N  N  N  N  N  N  N  N  N  N

PRR
a  X  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22
c 20 20 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 10 10
i 19 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 10  9  9
s  N  N  R  N  N  N  N  N  N  N  N  N  N

a: ack#; c: cwnd; i: inflight; s: sent

Analyse​

Dans ce premier exemple :

Séquence d'ACK :

  • Les ACK #1 à #19 transportent des SACK du vol de données original
  • Les ACK #20 et #21 transportent des SACK pour les deux segments déclenchés par limited transmit
  • L'ACK #22 transporte un ACK cumulatif complet couvrant toutes les données (y compris limited transmit)
  • L'ACK #22 complète la phase de récupération rapide, complétant ainsi la phase PRR

Comparaison des comportements :

  • Les deux algorithmes envoient la même quantité totale de données
  • Les deux terminent la récupération rapide avec cwnd correspondant à ssthresh à une valeur de 20
  • RFC 6675 subit un « silence d'une demi-fenêtre »
  • PRR répartit les réductions volontaires de fenêtre sur l'ensemble du RTT

Exemple 2 : Perte en rafale de 15 segments​

Ensuite, considérons le scénario d'exemple avec les mêmes conditions initiales, sauf que les 15 premiers paquets (0-14) sont perdus. Pendant le reste du RTT avec perte, seuls 5 ACK sont retournés à l'émetteur. Chaque algorithme est examiné séquentiellement ci-dessous.

RFC 6675
a  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X 15 16 17 18 19
c 20 20 10 10 10
i 19 19  4  9  9
s  N  N  6R  R  R

PRR
a  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X 15 16 17 18 19
c 20 20  5  5  5
i 19 19  4  4  4
s  N  N  R  R  R

a: ack#; c: cwnd; i: inflight; s: sent

Analyse​

Dans ce cas particulier :

Comportement RFC 6675 :

  • Une fois la retransmission rapide déclenchée (sur l'ACK du segment 17), l'émetteur retransmet immédiatement suffisamment de données pour que inflight augmente pour correspondre à cwnd
  • Les premières mesures (discutées dans la section 6 de [RFC6675]) montrent que [RFC6675] surpasse significativement la version [RFC6937] de PRR (qui n'utilisait que PRR-CRB) et d'autres algorithmes similaires testés
  • Cela démontre que les situations où les pertes réelles dépassent la réduction de cwnd déterminée par l'algorithme de contrôle de congestion sont très courantes

Comportement PRR :

  • Pendant le premier RTT de récupération rapide, PRR suit la conservation des paquets en utilisant PRR-CRB
  • Puisque les pertes totales maintiennent inflight en dessous de ssthresh, les données envoyées font que le total des données transmises prr_out suit le total des données signalées par les ACK de retour comme livrées au récepteur
  • Les transmissions sont contrôlées par la limite d'envoi, définie à prr_delivered - prr_out

Processus de récupération :

  • Bien que non illustré dans le diagramme, une fois que les retransmissions rapides envoyées à partir de l'ACK #17 sont livrées et provoquent des ACK qui augmentent SND.UNA, PRR entre dans PRR-SSRB
  • Augmente la fenêtre d'exactement 1 segment par ACK pendant la récupération jusqu'à ce que inflight atteigne ssthresh pendant la récupération
  • Pour les pertes sévères lorsque cwnd est grand, PRR-SSRB récupère exponentiellement plus rapidement que PRR-CRB
  • Bien qu'il puisse sembler imprudent d'augmenter la fenêtre pendant la récupération, il est important de se rappeler que c'est en fait plus conservateur que ce que [RFC6675] permet, qui envoie la même quantité de données supplémentaires en une seule rafale en réponse à l'ACK qui a déclenché la retransmission rapide

Cas de pertes légères : Pour les événements de perte moins sévères où les pertes totales sont inférieures à la différence entre FlightSize et ssthresh, PRR-CRB et PRR-SSRB ne sont pas invoqués car PRR reste en mode de réduction de taux proportionnelle.

Dernière mise à jour le