Was ist RACK?

„Recent Acknowledgment“ (RACK) ist ein TCP-Algorithmus zur Erkennung von Paketverlusten, der anhand der seit dem Versand verstrichenen Zeit beurteilt, ob ein Segment verloren gegangen ist, anstatt wie bei älteren TCP-Stacks doppelte Bestätigungen zu zählen. Diese Umstellung sorgt für eine genaue Erkennung von Paketverlusten bei der Paketneuordnung und bei „Tail Drops“, und die VOS-TCP-Optimierung von Versabietet RACK als wählbare Methode zur Erkennung von Paketverlusten an, um die Wiederherstellung zu beschleunigen.

Die wichtigsten Erkenntnisse

• RACK erkennt verlorene TCP-Segmente anhand der verstrichenen Zeit und nicht anhand der Anzahl doppelter ACKs.
• Es toleriert eine Neuordnung von Paketen, anstatt diese fälschlicherweise als Verlust zu interpretieren.
• Die Tail Loss Probe (TLP) arbeitet mit RACK zusammen, um Ausfälle im hinteren Teil eines Fluges zu erfassen.
• RACK-TLP, das in RFC 8985 standardisiert wurde, ist mittlerweile in modernen TCP-Stacks weit verbreitet.
• Die VOS-TCP-Optimierung bietet RACK als wählbare Methode zur Verlusterkennung an.

Auf dieser Seite: Warum das wichtig ist · So funktioniert es · Komponenten von RACK · RACK & Versa · Häufig gestellte Fragen

Warum ist RACK wichtig?

Die klassische TCP-Verlusterkennung – ein fester Schwellenwert für doppelte ACKs, der später durch die SACK-basierte Wiederherstellung verfeinert wurde – funktioniert auf einfachen Pfaden gut, versagt jedoch in zwei Situationen. Sie kann eine Neuordnung fälschlicherweise als Verlust interpretieren und ein Segment erneut übertragen, das lediglich verzögert wurde. Außerdem ist sie am Ende einer Datenübertragung blind: Sobald hinter einem verlorenen Segment keine Daten mehr in der Warteschlange stehen, löst nichts mehr die doppelten ACKs aus, die der alte Algorithmus benötigt, sodass die Wiederherstellung auf ein langsames Zeitlimit für die erneute Übertragung zurückgreift, anstatt eine nahezu sofortige schnelle erneute Übertragung durchzuführen.

RACK schließt beide Lücken, indem es statt der ACK-Zahlen die Zeit berücksichtigt und dies mit einem Abfrage-Mechanismus für den Tail-Fall kombiniert. „ Networks “, die mehrere zugrunde liegende Verbindungen kombinieren – eine Situation, die in SD-WAN-Fabrics regelmäßig auftritt –, weisen eine stärkere Umreihenfolge zwischen den Pfaden auf, und dank der Toleranz von RACK gegenüber diesem Phänomen bleiben Durchsatz und Latenz besser vorhersehbar.

Was ist RACK?

Jedes übertragene Segment erhält einen Sendezeitstempel. Wenn ein ACK- oder SACK-Block eintrifft, überprüft RACK jedes frühere, noch nicht bestätigte Segment und prüft, ob – gemessen an der jüngsten Round-Trip-Time-Messung der Verbindung – genügend Zeit vergangen ist, sodass das Segment als verloren und nicht nur als neu geordnet gelten muss. Dieser Schwellenwert ist das Reordering-Fenster: Ein Segment, dessen Bestätigung länger als etwa die aktuelle RTT aussteht, wird als verloren markiert und sofort erneut gesendet; ein verspätetes ACK für ein neu geordnetes Segment innerhalb des Fensters führt zu keiner erneuten Übertragung.

Durch die Verwendung des aktuellsten RTT-Werts anstelle eines Langzeitdurchschnitts kann RACK schnell auf Änderungen der Latenz reagieren. Für sich genommen prüft RACK lediglich, wann ein ACK eintrifft; daher benötigt es weiterhin einen Mechanismus für Stillstand – aus diesem Grund wird es in RFC 8985 mit „Tail Loss Probe“ kombiniert, anstatt RACK allein zu definieren.

Komponenten von RACK

RACK-TLP, wie in RFC 8985 standardisiert, besteht aus zwei Teilen. „Recent Acknowledgment“ (RACK) ist der oben beschriebene zeitbasierte Detektor: Er wird immer dann ausgeführt, wenn ein ACK- oder SACK-Block eintrifft, und ermittelt anhand der verstrichenen Übertragungszeit, ob nicht bestätigte Daten verloren gegangen sind. Tail Loss Probe (TLP) deckt den Bereich ab, den RACK allein nicht abdecken kann – eine Verbindung, die das Senden eingestellt hat, sodass kein neues ACK eintrifft, um einen Verlust aufzudecken. TLP startet einen kurzen Probe-Timer, und wenn vor dessen Ablauf kein ACK eintrifft, sendet es ein Probe-Segment – neue Daten, falls verfügbar, andernfalls eine Wiederholung des letzten Segments –, ausschließlich um Rückmeldung zu generieren.

Diese Rückmeldung bestätigt, dass die Daten angekommen sind, oder gibt RACK das Signal, das Segment als verloren zu erklären, wodurch das langsamere Timeout umgangen wird, auf das ältere Stacks andernfalls warten müssten.

RACK & Versa

VersaDie VOS-TCP-Optimierung bietet RACK als wählbare Methode zur TCP-Verlusterkennung an – die Einstellung „TCP Loss Detection“ ist standardmäßig auf die klassische Zählung doppelter ACKs eingestellt, wobei „Recent Acknowledgment“ (RACK) als Alternative vom Administrator aktiviert werden kann und gemäß der IETF-Spezifikation mit der zusätzlichen „Tail Loss Probe“ implementiert wird. SD-WAN-Pfade kombinieren oft mehrere zugrunde liegende Verbindungen mit unterschiedlichen Latenzen, sodass eine Neuordnung häufiger vorkommt als auf einem einzelnen, direkten Pfad – genau das toleriert RACK ohne unnötige Neuübertragung. Die Wiederherstellung nach Tail-Drop ist auch auf WAN-Pfaden von Bedeutung, wo ein verlorenes letztes Segment andernfalls einen Datenfluss blockieren würde, bis ein Timeout für die vollständige Neuübertragung abgelaufen wäre.

Häufig gestellte Fragen

Welches Problem löst RACK, das ältere Verfahren zur Erkennung von TCP-Datenverlusten nicht lösen konnte?

Die Zählung doppelter ACKs geht davon aus, dass eine feste Anzahl von ACKs in falscher Reihenfolge einen Verlust bedeutet, was bei gewöhnlicher Neuordnung zu Fehlalarmen führt, und liefert kein Signal, wenn das letzte Segment einer Datenübertragung verloren geht. RACK nutzt stattdessen die verstrichene Zeit und erfasst so beide Fälle, ohne dass durch normalen Jitter ausgelöste Neuübertragungen erfolgen.

Inwiefern unterscheidet sich RACK von der auf doppelten ACKs basierenden schnellen Neuübertragung?

Bei der „Fast Retransmit“-Methode wird nach einer festgelegten Anzahl doppelter ACKs ein Verlust gemeldet, unabhängig davon, wie viel Zeit tatsächlich verstrichen ist. RACK vergleicht hingegen die seit dem Versand eines Segments verstrichene Zeit mit der aktuellen Round-Trip-Zeit der Verbindung, sodass es ein langsames, neu angeordnetes Paket von einem tatsächlich verlorenen unterscheiden kann.

Was ist eine „Tail Loss Probe“ und in welchem Zusammenhang steht sie mit RACK?

TLP ist der Begleitmechanismus von RACK für den Fall, dass eine Verbindung keine Daten mehr sendet, sodass kein neues ACK eintreffen kann, um einen Verlust aufzudecken. TLP startet einen kurzen Timer und sendet ein Testsegment, wenn kein ACK eintrifft, wodurch das Feedback erzeugt wird, das RACK benötigt, um den Verlust schnell zu erkennen.

Ist RACK der Standardalgorithmus zur Verlusterkennung auf modernen Systemen?

RACK-TLP wurde 2021 als RFC 8985 standardisiert und hat sich seitdem zum Standardmechanismus für die Wiederherstellung verlorener Daten in gängigen Protokollstacks, darunter auch Linux, entwickelt. Es existiert neben SACK, anstatt dieses zu ersetzen, da RACK weiterhin auf SACK-Informationen zurückgreift, um fehlende Segmente zu identifizieren.

Ersetzt RACK TCP SACK?

Nein. SACK (Selective Acknowledgment) teilt dem Absender mit, welche Segmente angekommen sind, und RACK nutzt diese Informationen als Eingabe. RACK ist die Entscheidungsebene, die SACK-Daten und Übertragungszeitstempel auswertet, um zu entscheiden, wann genügend Zeit vergangen ist, um eine Lücke als Verlust zu werten – es ist kein Ersatz für SACK selbst.

Mehr über RACK

Wenn Sie mehr erfahren möchten, finden Sie hier Quellen, denen wir vertrauen.

Verwandte Begriffe

Wenn Sie sich gerade über RACK informieren, sollten Sie sich als Nächstes diese Artikel ansehen.