Zum Hauptinhalt springen

8. Beispiele (Examples)

Dieser Abschnitt veranschaulicht das Verhalten der PRR- und [RFC6675]-Algorithmen, indem gezeigt wird, wie sie sich in ihrer Reaktion auf zwei Beispielszenarien unterscheiden: eine Verbindung, die den Verlust eines einzelnen Pakets erfährt, oder einen Burst von 15 aufeinanderfolgenden verlorenen Paketen.

Test-Szenario-Setup​

Alle Fälle verwenden:

  • Bulk-Datenübertragung (keine Anwendungspausen)
  • Reno-Staukontrolle [RFC5681]
  • Ausgangszustand: cwnd = FlightSize = inflight = 20 Segmente
  • ssthresh: Wird zu Beginn der Wiederherstellung auf 10 gesetzt
  • Fast Retransmit: Verwendet standardmäßiges Fast Retransmit [RFC5681]
  • Limited Transmit [RFC3042]: Sendet 2 neue Segmente + 1 Neuübertragung als Reaktion auf die ersten drei doppelten ACKs

Diagrammerklärung​

Die folgenden Diagramme zeigen die Reaktion pro ACK für die erste Rundreise nach dem Verlust von Segment 0. Die oberste Zeile („ack#") zeigt die Segmentnummer an, die das ACK ausgelöst hat, wobei X verlorene Segmente anzeigt.

Die Zeilen „cwnd" und „inflight" zeigen die Werte von cwnd und inflight dieser Algorithmen nach der Verarbeitung jedes zurückkehrenden ACK, aber vor weiteren (Neu-)Übertragungen. Die Zeile „sent" gibt an, wie viele „N" neue Daten oder „R" Neuübertragungen gesendet werden.

Beispiel 1: Einzelner Segmentverlust​

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​

In diesem ersten Beispiel:

ACK-Sequenz:

  • ACKs #1 bis #19 tragen SACKs des ursprünglichen Datenflugs
  • ACKs #20 und #21 tragen SACKs für die beiden durch Limited Transmit ausgelösten Segmente
  • ACK #22 trägt ein vollständiges kumulatives ACK, das alle Daten (einschließlich Limited Transmit) abdeckt
  • ACK #22 schließt die Fast-Recovery-Phase ab und damit die PRR-Phase

Verhaltensvergleich:

  • Beide Algorithmen senden die gleiche Gesamtmenge an Daten
  • Beide beenden Fast Recovery mit cwnd, das ssthresh bei einem Wert von 20 entspricht
  • RFC 6675 erfährt ein „Halbes-Fenster-Schweigen"
  • PRR verteilt freiwillige Fensterreduktionen über den gesamten RTT

Beispiel 2: Burst-Verlust von 15 Segmenten​

Als Nächstes betrachten wir das Beispielszenario mit denselben Ausgangsbedingungen, außer dass die ersten 15 Pakete (0-14) verloren gehen. Während des Rests des verlustbehafteten RTT werden nur 5 ACKs an den Sender zurückgegeben. Jeder Algorithmus wird im Folgenden der Reihe nach untersucht.

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​

In diesem speziellen Fall:

RFC 6675-Verhalten:

  • Sobald Fast Retransmit ausgelöst wird (beim ACK von Segment 17), überträgt der Sender sofort genügend Daten, damit inflight auf cwnd ansteigt
  • Frühe Messungen (diskutiert in Abschnitt 6 von [RFC6675]) zeigen, dass [RFC6675] die [RFC6937]-Version von PRR (die nur PRR-CRB verwendete) und andere ähnlich konservative getestete Algorithmen erheblich übertrifft
  • Es zeigt, dass Situationen, in denen die tatsächlichen Verluste die vom Staukontrollalgorithmus bestimmte cwnd-Reduktion überschreiten, sehr häufig sind

PRR-Verhalten:

  • Während des ersten RTT der Fast Recovery folgt PRR der Paketerhaltung mit PRR-CRB
  • Da die Gesamtverluste inflight unter ssthresh halten, sorgen die gesendeten Daten dafür, dass die insgesamt übertragenen Daten prr_out den Gesamtdaten folgen, die von zurückkehrenden ACKs als an den Empfänger geliefert gemeldet werden
  • Übertragungen werden durch das Sendelimit gesteuert, das auf prr_delivered - prr_out gesetzt ist

Wiederherstellungsprozess:

  • Obwohl nicht im Diagramm gezeigt, tritt PRR in PRR-SSRB ein, sobald die ab ACK #17 gesendeten schnellen Neuübertragungen geliefert werden und ACKs verursachen, die SND.UNA erhöhen
  • Erhöht das Fenster während der Wiederherstellung um genau 1 Segment pro ACK, bis inflight während der Wiederherstellung ssthresh erreicht
  • Bei schweren Verlusten, wenn cwnd groß ist, erholt sich PRR-SSRB exponentiell schneller als PRR-CRB
  • Obwohl es unklug erscheinen mag, das Fenster während der Wiederherstellung zu erhöhen, ist es wichtig zu bedenken, dass dies tatsächlich konservativer ist als das, was [RFC6675] erlaubt, das die gleiche Menge zusätzlicher Daten als einzelnen Burst als Reaktion auf das ACK sendet, das Fast Retransmit ausgelöst hat

Leichte Verlustfälle: Bei weniger schwerwiegenden Verlustereignissen, bei denen die Gesamtverluste geringer sind als die Differenz zwischen FlightSize und ssthresh, werden PRR-CRB und PRR-SSRB nicht aufgerufen, da PRR im Modus der proportionalen Ratenreduktion bleibt.

Letztes Update am