Zum Hauptinhalt springen

6.1.3. Der TCP-Empfänger (The TCP Receiver)

Dieser Abschnitt spezifiziert das Verhalten des TCP-Datenempfängers bei Verwendung von ECN.

6.1.3.1. Überprüfung eingehender Pakete​

Für jedes empfangene Datensegment MUSS der TCP-Empfänger:

  1. Das ECN-Feld im IP-Header überprüfen
  2. Erkennen, ob das CE-Codepoint gesetzt ist
  3. Den Status verfolgen für ECE-Flag-Verwaltung

6.1.3.2. Setzen des ECN-Echo (ECE) Flags​

Wenn ein Paket mit CE-Codepoint empfangen wird:

Der Empfänger MUSS:

  • Das ECE-Flag in nachfolgenden ACK-Segmenten setzen
  • ECE gesetzt halten, bis ein Segment mit gesetztem CWR-Flag empfangen wird
  • Dies gilt unabhängig davon, ob weitere CE-Pakete empfangen werden oder nicht

Wenn ein Paket mit ECT(0) oder ECT(1) empfangen wird (kein CE):

  • Keine spezielle Aktion erforderlich
  • ECE-Status bleibt unverändert

Wenn ein Paket mit Not-ECT empfangen wird:

  • Keine ECN-Verarbeitung
  • Normal ACK senden

6.1.3.3. ECE-Flag-Zustandsmaschine​

Der Empfänger pflegt einen ECE-Status für die Verbindung:

Zustand 1: Kein CE empfangen (Initial)​

  • ECE = 0 in ausgehenden ACKs
  • Übergang: Beim Empfang von CE → Zustand 2

Zustand 2: CE empfangen, ECE-Benachrichtigung läuft​

  • ECE = 1 in ausgehenden ACKs
  • Übergang: Beim Empfang von CWR → Zustand 1

6.1.3.4. Empfang von CWR-Flag​

Wenn der Empfänger ein Segment mit gesetztem CWR-Flag empfängt:

  1. Der Sender hat die ECE-Benachrichtigung bestätigt
  2. Der Empfänger SOLLTE das ECE-Flag löschen in nachfolgenden ACKs
  3. Zurück zum normalen Zustand (bis nächstes CE empfangen wird)

6.1.3.5. Mehrere CE-markierte Pakete​

Wenn mehrere aufeinanderfolgende Pakete mit CE empfangen werden:

  • Der Empfänger hält ECE gesetzt in allen ACKs
  • Keine Zählung erforderlich - binäres Signal (ECE an/aus)
  • Der Sender reagiert einmal pro RTT basierend auf ECE-Präsenz

6.1.3.6. ACK-Generierung​

Der Empfänger MUSS:

  • Normale TCP-ACK-Generierungsregeln befolgen
  • ECE zusätzlich zu normalen ACK-Informationen setzen
  • Nicht verzögerte ACKs aufgrund von ECE erzwingen (delayed ACKs sind weiterhin zulässig)

6.1.3.7. Reine ACK-Segmente​

Für reine ACK-Segmente (ohne Daten):

  • KÖNNEN Not-ECT im IP-Header verwenden
  • ODER KÖNNEN ECT verwenden (wenn ECN für Verbindung verhandelt wurde)
  • MÜSSEN ECE korrekt setzen basierend auf empfangenen CE-Paketen

6.1.3.8. ACKs von Daten mit CE​

Wenn ein Datensegment mit CE empfangen wird:

  1. Daten werden normal verarbeitet
  2. ACK wird wie gewohnt generiert
  3. ECE-Flag wird im ACK gesetzt
  4. Keine andere spezielle Behandlung des Segments erforderlich

6.1.3.9. Außer-Ordnung-Segmente​

Wenn ein außer-Ordnung-Segment mit CE empfangen wird:

  • Behandle CE-Markierung normal (setze ECE)
  • Normale außer-Ordnung-Verarbeitung gilt
  • SACK-Informationen (falls verwendet) sind unabhängig von ECN

6.1.3.10. Verbindungsabschluss​

Während der Verbindungsbeendigung (FIN-Austausch):

  • ECE-Mechanismus bleibt aktiv
  • FIN-Segmente KÖNNEN ECT verwenden
  • Letzte ACKs SOLLTEN ECE reflektieren wenn anwendbar

6.1.3.11. Interaktion mit TCP-Optionen​

ECE-Verarbeitung ist unabhängig von:

  • TCP-Zeitstempeln
  • TCP-SACK
  • Anderen TCP-Optionen

Diese Optionen funktionieren normal neben ECN.

6.1.3.12. Robustheit​

Der Empfänger SOLLTE robust sein gegenüber:

  • Verlorenen CWR-Segmenten: Fortsetzung des Sendens von ECE, bis CWR empfangen wird
  • Doppelten CE-Paketen: Keine spezielle Behandlung erforderlich
  • Gemischten ECT(0) und ECT(1): Beide gleich behandeln
Letztes Update am