Zusammenfassung

  • RFC 9768 macht den TCP-Empfänger zu einem generischen mechanischen Reflektor von ECN-Informationen; die Staureaktion entscheidet der Datensender.
  • Der unverzichtbare Drei-Bit-ACE-Zähler und die optionalen 24-Bit-Bytezähler haben verschiedene Verlust-, Überlauf- und Middlebox-Grenzen.
  • Ein belastbarer Betriebsbeleg trennt Aushandlung, Zählung, Rekonstruktion, Ursachenannahme und Senderaktion, statt eine CE-Zunahme als Warteschlangenmessung auszugeben.

Ein Protokoll unter Platzdruck

Das klassische TCP-ECN kann pro Umlauf höchstens eine Stauanzeige zurückmelden. Ob ein oder viele Pakete CE-markiert waren, bleibt dem Sender verborgen. Für proportionale Antworten wie DCTCP und skalierbare Signalisierung wie L4S ist das zu wenig. RFC 9768 wurde im April 2026 als Standards-Track-Dokument veröffentlicht und aktualisiert die TCP-Aushandlung und Rückmeldung von RFC 3168.

AccECN standardisiert jedoch keine Staukontrolle. Der Empfänger zählt die ECN-Codepoints akzeptabler Segmente und spiegelt seinen Zustand. Der Sender kennt die ursprünglich gesetzten ECT-Werte, prüft die Rückmeldung und entscheidet lokal über seine Antwort. Der Empfänger bleibt dadurch für künftige Senderalgorithmen unverändert nutzbar.

Die Formulierung „generischer mechanischer Reflektor“ ist eine Zuständigkeitsgrenze: bessere Beobachtung bedeutet nicht, dass der Empfänger den Sender steuert.

ACE als unverzichtbarer Rückfall

Der AccECN Counter verwendet die drei TCP-ECN-Flags und überträgt die unteren drei Bits des CE-Paketzählers. Der Empfänger wiederholt den aktuellen Stand. Geht ein ACK verloren, kann ein späteres ACK den aufgelaufenen Unterschied noch zeigen.

Mit nur acht Zuständen läuft ACE häufig um. Auf sechs folgendes eins hat den minimalen modularen Abstand drei; eine längere ACK-Lücke kann eine zusätzliche Runde verbergen. Verzögerung, Filterung und Umordnung verändern die Rekonstruktion. RFC 9768 verlangt ausreichend häufige ACKs und gibt strengere Empfehlungen abhängig von unbestätigten Daten. Ohne Detailoption muss der Sender dennoch eine konservative Umlaufannahme dokumentieren.

ACE zählt akzeptable CE-markierte TCP-Pakete einschließlich Steuerpaketen und Wiederholungen, ausgenommen SYN. Es ist kein Zähler eindeutiger Anwendungsbytes. Wer beide Größen gleichsetzt, erzeugt bei jeder Wiederholung scheinbare Widersprüche.

Die optionale Genauigkeit

Die AccECN-Option trägt die unteren 24 Bits dreier Nutzlastzähler für CE, ECT(0) und ECT(1). Header zählen nicht, wiederholte Nutzlast schon. Ein unbemerkter Vollumlauf ist während realistischer ACK-Ausfälle äußerst unwahrscheinlich, sodass ein Sender Markierungsanteile besser bestimmen kann.

Doch TCP-Optionen sind knapper Raum. Wenn die minimale AccECN-Option nicht neben zwei SACK-Blöcke passt, hat SACK Vorrang. Ein Middlebox kann unbekannte Optionen streichen, ein Proxy die Verbindung teilen, GRO/LRO die Beobachtung gruppieren. Die Option kann während derselben Verbindung verschwinden oder wieder auftauchen.

Darum ergänzt sie ACE und ersetzt es nie. Der feste Header liefert eine grobe Grundspur; die Option eine reichere, bedingte Spur. Der Sender führt Baselines und gleicht modulare Differenzen ab, wobei Paket- und Byteeinheiten verschieden bleiben.

Aushandlung mit eingebautem Zukunftsraum

AE, CWR und ECE bilden in der Dreiwege-Aushandlung Muster für AccECN und Rückfälle auf klassisches oder kein ECN. Wegen knappen SYN-Raums erscheint die AccECN-Option nicht im ersten SYN; ihre Durchlässigkeit wird mit SYN/ACK und erstem ACK getestet. Ein erfolgreicher AccECN-Handshake beweist daher nicht, dass 24-Bit-Zähler verfügbar sind.

Bewusst von null verschiedene Anfangswerte helfen zustandsloser Verarbeitung und zeigen systematisches Nullsetzen. Ein Endpunkt darf trotzdem keinen einzigen exakten Startwert verlangen, weil er sonst künftige Erweiterungszustände verbraucht. Umordnung kann sogar einen legitimen ersten ACE-Wert null erzeugen.

Das ist minimale Anfangsspezifikation: global wird nur festgelegt, was Interoperabilität und Fehlererkennung brauchen. Die spätere Antwort bleibt beim Sender, der sie einseitig weiterentwickeln kann.

Wenn der Pfad die Aussage verändert

ECN-Felder können in nur einer Richtung gebleicht oder umgeschrieben werden. Optionen können verschwinden, ACKs gefiltert werden. Der Empfänger kennt den ursprünglichen Sendewert nicht und soll deshalb mechanisch reflektieren. Der Datensender besitzt die nötige Vergleichsbasis.

Steigt der CE-Bytezähler, ohne dass der Paketzähler nach einer legitimen Erklärung folgen kann, prüft der Sender Wiederholungen, Einheiten, ACK-Verlust, Umlauf und Optionswechsel. Bleibt der Widerspruch bestehen, kann er ECT für diese Halbverbindung abschalten. Das ist lokale Eindämmung, keine forensische Zuordnung eines Geräts.

CE belegt den Codepoint beim Empfang. Es nennt weder Warteschlangenlänge, Schwelle, Betreiber noch Anwendungsschaden und schreibt keine bestimmte Reduktion vor. DCTCP, CUBIC und skalierbare Verfahren können dieselbe Reihe unterschiedlich behandeln.

Der Betriebsbeleg muss je Richtung Handshake-Flags, gesendete und empfangene ECN-Werte, ACE-Folge und modulare Deltas, Baselines der drei Bytezähler, Optionsform und -verfügbarkeit, ACK-Lücken, SACK-Druck, Wiederholungen, Offload, Proxy, Abgleich, ECT-Entscheidung und Senderalgorithmus enthalten. Warteschlangen-, Durchsatz- und Anwendungsmessungen bleiben eigenständige Belege.

Tests sollten einzelne und viele ACKs verlieren, einen Vollumlauf verbergen, das erste ACK umordnen, die Option nachträglich streichen, Optionsraum mit SACK füllen und ECN asymmetrisch verändern. Korrektes Verhalten heißt nicht immer volle Genauigkeit, sondern nachvollziehbare Abstufung ohne erfundene Gewissheit.

Quellen