1. Einleitung (Introduction)

Überlastung (Congestion) im Internet wird derzeit hauptsächlich durch Paketverlust (packet dropping) als impliziter Mechanismus behandelt, sowohl für die Meldung von Überlastung an Endknoten (end-nodes) als auch in einigen Fällen für die Durchsetzung der Fairness (fairness). Die Explicit Congestion Notification (ECN) wurde als Ergänzung zu diesem traditionellen Überlastungskontrollmechanismus vorgeschlagen, um dem Internet-Protokoll eine explizitere Benachrichtigung über Netzwerküberlastung zu ermöglichen.

Bei ECN verwenden Router eine Überlastungsanzeige (congestion indication) in einem Paket-Header, um bevorstehende Überlastung zu signalisieren, anstatt Pakete zu verwerfen. Die Benachrichtigung über die empfangene Überlastungsanzeige wird dann durch das Transportprotokoll an den Sender zurückgegeben.

Die Explicit Congestion Notification wurde für eine Vielzahl von Szenarien vorgeschlagen, von "grünem" Paketverlust in RED-Gateways (Random Early Detection) bis hin zu Mechanismen zur lokalen Durchsetzung der Fairness in Quality-of-Service (QoS) Umgebungen. Diese Spezifikation legt die Grundlage für ECN in IP und TCP fest.

Dieser Vorschlag schlägt die Verwendung von zwei Bits im IP-Header (IPv4 oder IPv6) für ECN vor. Ein Bit wird vom Sender gesetzt, um anzuzeigen, dass das Ende (end-points) des Transportprotokolls ECN-fähig (ECN-capable) ist. Das andere Bit wird von Routern gesetzt, um Überlastung anzuzeigen. Pakete, bei denen beide Bits gesetzt sind, sollten als Überlastungserfahrung (Congestion Experienced, CE) interpretiert werden.

1.1. Hauptziele von ECN

Die Hauptziele der Explicit Congestion Notification sind:

1. Vermeidung von unnötigem Paketverlust: Durch die Signalisierung von Überlastung, bevor die Warteschlange voll ist, kann ECN Paketverlust vermeiden und gleichzeitig dem Sender mitteilen, dass er seine Übertragungsrate reduzieren sollte.

2. Verbesserte Leistung für interaktive Anwendungen: Für Echtzeitanwendungen (real-time applications) kann die Vermeidung von Paketverlust die wahrgenommene Qualität erheblich verbessern.

3. Kompatibilität mit bestehendem Verhalten: ECN ist vollständig abwärtskompatibel (backwards compatible) mit nicht-ECN-fähigen Hosts und Routern.

4. Inkrementelle Bereitstellung: ECN kann schrittweise bereitgestellt werden. Nicht-ECN-fähige Router können mit ECN-fähigen Hosts koexistieren, und umgekehrt.

1.2. ECN-Codepoints im IP-Header

ECN verwendet die folgenden zwei Bits im IP-Header:

ECT-Bit (ECN-Capable Transport): 
  Wird vom Sender gesetzt, um anzuzeigen, dass die Endpunkte ECN-fähig sind.

CE-Bit (Congestion Experienced):
  Wird von Routern gesetzt, um Überlastung anzuzeigen.

Die vier möglichen Kombinationen dieser zwei Bits ergeben die folgenden ECN-Codepoints:

• '00' - Not-ECT (Not ECN-Capable Transport): Paket unterstützt keine ECN
• '01' - ECT(1) (ECN-Capable Transport(1)): ECN-fähiges Paket (Variante 1)
• '10' - ECT(0) (ECN-Capable Transport(0)): ECN-fähiges Paket (Variante 0)
• '11' - CE (Congestion Experienced): Überlastung erfahren

1.3. Anwendungsbereich

Diese Spezifikation konzentriert sich auf die Verwendung von ECN mit TCP als Transportprotokoll. Die Mechanismen sind jedoch so konzipiert, dass sie allgemein auf andere Transportprotokolle anwendbar sind, die eine Überlastungskontrolle implementieren.

1.4. Dokumentstruktur

Der Rest dieses Dokuments ist wie folgt strukturiert:

• Kapitel 2-4: Konventionen, Annahmen und Hintergrund zu Active Queue Management
• Kapitel 5: Spezifikation von ECN im IP-Layer
• Kapitel 6: Spezifikation von ECN-Unterstützung in TCP
• Kapitel 7-10: Behandlung von Nicht-Konformität und speziellen Szenarien
• Kapitel 11-13: Evaluierungen, Zusammenfassung und Schlussfolgerungen
• Kapitel 14-16: Metainformationen und Sicherheit
• Anhänge A-I: Technische Details und erweiterte Diskussionen

---

Hinweis: Diese Spezifikation macht RFC 2481 obsolet und stellt die aktualisierte und verbesserte Definition von ECN für IP-Netzwerke dar.