Zusammenfassung

  • Strikte ACK-Priorität kann einen vorwärts laufenden TCP-Strom beschleunigen und zugleich Upstream-Daten verdrängen; der Download allein ist daher kein Fairnessbeleg.
  • Asymmetrische Pfade verändern ACK-Abstand, Fensterwachstum, Burst und Recovery auf unterschiedliche Weise. Jede Verbesserung braucht richtungsbezogene und anwendungsbezogene Belege.

Der Scheduler traf eine scheinbar vernünftige Entscheidung: kleine ACKs durften an großen Upload-Paketen vorbeiziehen. Die Rückmeldung für den Download wurde schneller, und der Durchsatztest sprang auf Grün.

Nur der Upload bewegte sich kaum noch. Seine Pakete verloren jeden Wettbewerb gegen eine fortlaufende ACK-Schlange. Die Politik hatte eine Feedback-Latenz geheilt und eine andere Anwendung aus dem Erfolgskriterium entfernt.

RFC 3449 erschien im Dezember 2002 als BCP 69. Das Dokument führt ACKs-first scheduling als nicht empfohlen für den allgemeinen Internet-Einsatz. Nicht weil niedrige ACK-Latenz wertlos wäre, sondern weil unbegrenzte Priorität keine faire Ressourcenregel ist.

Der Rückweg steuert die Vorwärtsleistung

Ein kumulatives ACK bestätigt Sequenzfortschritt beim Empfänger. Es öffnet das Sendefenster, beeinflusst congestion-window growth und liefert Signale für loss recovery. Eine Anwendungsausführung bestätigt es nicht.

Beim self-clocking prägt der Vorwärtsengpass den Abstand der Datenpakete. Der Empfänger sendet ACKs, deren Rückkehr neue Daten freigibt. Ein schmaler oder pro Paket teurer Rückweg kann diese Uhr begrenzen, obwohl die Vorwärtsleitung frei ist.

Eine Leistungsakte benötigt deshalb beide Routen, Kapazität, MAC-Kosten, cross traffic, Queue-Regel und ACK policy. Ein Downloadwert reicht nicht.

Tiefe und flache Queues scheitern anders

In einer tiefen Rückwärtsqueue warten ACKs. ACK dilation vergrößert ihre Abstände, der Sender taktet am schmalen Rückweg, RTT steigt und window growth verlangsamt sich. Die Vorwärtsleitung kann ohne Vorwärtsverlust leer bleiben.

In einer flachen Queue fallen ACKs aus. Ein späteres kumulatives ACK kann alle Bytes abdecken, doch duplicate ACK oder SACK für Fast Retransmit fehlen. Ein stretch ACK kann außerdem eine große Datenmenge auf einmal freigeben.

Bytefortschritt, Timing und Recovery-Beweis sind getrennte Größen. Die Queue-Tiefe entscheidet, welcher Teil sichtbar beschädigt wird.

Kompression macht aus Wartezeit einen Burst

Große Upload-Pakete können ACKs blockieren. Werden mehrere anschließend gemeinsam freigegeben, kommen sie beim Sender enger an als sie erzeugt wurden: ACK compression. Der Sender antwortet mit einem Vorwärtsburst, der dort eine Queue überlaufen lassen kann.

Die Rückwärtsqueue hat nicht nur verzögert, sondern die Senderaktion geformt. Receiver emission, Queue-Eintritt und -Austritt, sender reception, Burst-Größe und folgender loss müssen zeitlich korreliert werden.

Das Zahlenbeispiel von RFC 3449 – 10 Mbps vorwärts, 50 Kbps zurück, 1.000-Byte-Daten und 40-Byte-ACK – ergibt normalisiert k = 8. Es erklärt einen Mechanismus und misst kein heutiges Netz.

Priorität beantwortet nur eine lokale Frage

ACKs-first verringert Wartezeit, solange ACKs an Daten vorbeiziehen dürfen. Ohne Volumenkontrolle kann diese Regel Upstream-Daten dauerhaft verdrängen. Die Download-Anwendung gewinnt, weil eine andere Last ihre Ressource verliert.

Fair queuing wurde als ausgewogenere Empfehlung behandelt. Es trennt Flows und verhindert, dass ACKs unbegrenzt hinter großen Paketen stecken, ohne ihnen absolute Hoheit zu geben. Auch das muss unter echter bidirektionaler Last geprüft werden.

Ein Test, der nur forward goodput misst, ist für Scheduler-Entscheidungen falsch begrenzt. Er muss Upstream-Latenz, Durchsatz, starvation und Anwendungserfolg einschließen.

ACK-Reduktion verschiebt die Last

ACK Filtering entfernt redundante kumulative ACKs vor dem Engpass. Das spart Rückwegpakete, kann aber größere stretch ACK und Senderbursts erzeugen. RFC 3449 stufte es als experimentell ein und verlangte burst mitigation.

ACK Decimation nutzt Queue- und Drop-Regeln gröber und kann Recovery-Signale schlechter auswählen. Ein generell verlängerter delayed-ACK-Faktor war nicht empfohlen. Eine größere MSS ohne Routerfragmentierung war bei passendem PMTU empfohlen; absichtliche Fragmentierung war es nicht.

Jede Maßnahme braucht einen Beleg dafür, welche Ressource sie entlastet, welches Signal sie ausdünnt und welche andere Queue das Ergebnis trägt.

Rekonstruktion und Pacing besitzen verschiedene Autorität

ACK Reconstruction fügt nach dem Engpass Nachrichten aus soft state ein. Sie stammen nicht aus neuen Empfängerbeobachtungen. RFC 3449 stufte das Verfahren als nicht empfohlen ein und nannte amplification risk bei manipulierten stretch ACKs.

Sender Pacing verteilt dagegen bereits erlaubte Daten über Zeit. Es erfindet kein Empfängersignal, benötigt aber eine Ratenschätzung und galt als experimentell. Byte Counting verändert wiederum window growth; ohne Begrenzung kann ein großes ACK zu viel freigeben.

Eine glattere Kurve sagt deshalb nicht, ob Beobachtung, Netzwerkentscheidung oder lokale Aktion verändert wurde.

Geschützte Header setzen eine Zuständigkeitsgrenze

Filtering, compression und reconstruction setzen oft Sicht oder Änderung des TCP-Headers voraus. Verschlüsselung oder Integritätsschutz können diese Fähigkeit entfernen. Das ist kein Sicherheitsfehler, sondern eine Grenze für transparente Netzautorität.

Wer eine Optimierung plant, muss ihre Funktion bei geschütztem Header, anderen TCP-Varianten und fehlender Middlebox-Sicht dokumentieren. Ein stillschweigender Anspruch auf Endpoint-Daten ist keine robuste Abhängigkeit.

Zwölf Belege statt eines grünen Downloads

Zuerst beide Routen, Kapazitäten, MAC-Ereigniskosten, cross traffic, Queue und Buffer erfassen. Dann ACK policy und tatsächliches Empfänger-Timing sichern.

Loss, filtering, decimation, compression, reconstruction und scheduling werden einzeln attribuiert. Beim Sender gehören ACK-Abstände, cumulative progress, duplicate/SACK, cwnd, pacing und Burst-Verteilung dazu.

Vorwärtsverlust und Recovery, goodput mit offered load und fairness, authentifizierter Anwendungsabschluss und Nutzerergebnis sind eigene Belege. Rollback und alternate path schließen die Kausalität.

Beweisgrenze

RFC 3449 beweist kein heutiges Verhalten eines benannten Betreibers, Satelliten-, Funk- oder Kabelnetzes, TCP-Stacks oder congestion controllers. k = 8 ist ein Beispiel. Spätere TCP-Arbeiten verändern Algorithmen, nicht den Bedarf an Feedback und Recovery-Evidenz.

Heng Lus Prinzipien einer minimalen Anfangsspezifikation und des Vorrangs laufenden Codes sind offengelegte redaktionelle Perspektiven. Sie bevorzugen begrenzte, lokal überprüfte Eingriffe; Deployment-Fakten liefern sie nicht.

Quellen