Zum Hauptinhalt springen

3. Annahmen und allgemeine Prinzipien (Assumptions and General Principles)

Dieses Kapitel beschreibt die allgemeinen Annahmen und Prinzipien, die der ECN-Spezifikation zugrunde liegen.

3.1. Inkrementelle Bereitstellung (Incremental Deployment)​

ECN ist so konzipiert, dass es inkrementell bereitgestellt werden kann. Nicht-ECN-fähige Router können mit ECN-fähigen Endpunkten koexistieren und umgekehrt. Das Fehlen von ECN-Unterstützung in einem Teil der Infrastruktur führt nicht zu Fehlfunktionen, sondern lediglich zum Verzicht auf die Vorteile von ECN in diesem Segment.

3.1.1. Abwärtskompatibilität (Backwards Compatibility)​

ECN MUSS vollständig abwärtskompatibel mit nicht-ECN-fähigen Hosts und Routern sein. Insbesondere:

  • Ein nicht-ECN-fähiger Router SOLL ECN-Markierungen ignorieren und normal funktionieren
  • Ein nicht-ECN-fähiger Host kann mit ECN-fähigen Hosts kommunizieren
  • Eine Verbindung zwischen einem ECN-fähigen und einem nicht-ECN-fähigen Host wird ohne ECN fortgesetzt

3.2. End-to-End-Prinzip (End-to-End Principle)​

ECN folgt dem End-to-End-Prinzip der Internetarchitektur. Die Interpretation und Reaktion auf ECN-Signale ist primär die Verantwortung der Endpunkte. Router signalisieren lediglich Überlastung; die Entscheidung, wie darauf zu reagieren ist, liegt bei den Endpunkten.

3.2.1. Vertrauensmodell (Trust Model)​

Diese Spezifikation geht von einem bestimmten Vertrauensmodell aus:

  1. Router werden als vertrauenswürdig angesehen, das CE-Codepoint korrekt zu setzen, wenn sie Überlastung erfahren
  2. Endpunkte werden ermutigt, angemessen auf ECN-Signale zu reagieren
  3. Es gibt keine kryptographischen Mechanismen, um die Integrität von ECN-Signalen zu gewährleisten

3.3. Überlastungskontrolle (Congestion Control)​

ECN ist ein Mechanismus zur Überlastungsbenachrichtigung, nicht zur Überlastungskontrolle selbst. Die eigentliche Überlastungskontrolle wird von den Endpunkten durchgeführt, typischerweise durch das Transportprotokoll (z.B. TCP).

3.3.1. Äquivalenz von CE und Paketverlust​

Ein wesentliches Prinzip ist, dass das Empfangen eines CE-Codepoints als äquivalent zum Verlust eines Pakets behandelt werden SOLLTE, in Bezug auf die Überlastungskontrollreaktion.

Dies bedeutet:

  • Der Sender SOLLTE sein Überlastungsfenster in ähnlicher Weise reduzieren, wie er es bei einem Paketverlust tun würde
  • Die Reaktion SOLLTE nicht schwächer sein als die Reaktion auf Paketverlust
  • Die Reaktion SOLL nicht aggressiver sein als die Reaktion auf Paketverlust

3.4. Aktive Warteschlangenverwaltung (Active Queue Management)​

ECN ist eng mit Active Queue Management (AQM) Mechanismen wie RED (Random Early Detection) verbunden. AQM-Mechanismen in Routern:

  • Erkennen beginnende Überlastung, bevor Warteschlangen vollständig gefüllt sind
  • Verwenden probabilistische Mechanismen zur Überlastungsbenachrichtigung
  • Können entweder Pakete verwerfen (traditionell) oder das CE-Codepoint setzen (mit ECN)

3.5. Transparenz (Transparency)​

ECN-Mechanismen SOLLTEN so transparent wie möglich für Anwendungen sein. Die ECN-Unterstützung wird auf der IP- und Transportebene implementiert; Anwendungen müssen normalerweise nicht ECN-bewusst sein.

3.6. Fairness (Fairness)​

Die Einführung von ECN SOLL die Fairness zwischen verschiedenen Flüssen nicht beeinträchtigen. Insbesondere:

  • ECN-fähige Flüsse SOLLEN keinen unfairen Vorteil gegenüber nicht-ECN-fähigen Flüssen haben
  • Die Überlastungskontrollreaktionen SOLLEN vergleichbar sein
  • Router-Mechanismen SOLLEN ECN-fähige und nicht-ECN-fähige Pakete gleichmäßig behandeln

3.7. Robustheit (Robustness)​

Das ECN-Design MUSS robust gegenüber verschiedenen Fehlermodi sein:

3.7.1. Fehlerhaftes Verhalten von Endpunkten​

  • Ein Endpunkt, der fälschlicherweise ECN-Fähigkeit anzeigt, aber nicht angemessen reagiert, SOLL Paketverlust erleiden
  • Die Netzleistung für andere Flüsse SOLL nicht wesentlich beeinträchtigt werden

3.7.2. Fehlerhaftes Verhalten von Routern​

  • Ein Router, der ECN-Bits fälschlicherweise setzt oder löscht, SOLL hauptsächlich die betroffenen Flüsse beeinträchtigen
  • Der Mechanismus SOLL nicht zu netzwerkweiten Störungen führen

3.7.3. Middlebox-Interferenz​

  • ECN MUSS robust gegenüber Middleboxen sein, die ECN-Bits möglicherweise löschen oder ändern
  • Verbindungen SOLLEN auch dann funktionieren, wenn Middleboxen ECN-Verhandlung stören

3.8. Konservative Erweiterung (Conservative Extension)​

Diese Spezifikation nimmt einen konservativen Ansatz zur Erweiterung des IP-Protokolls:

  • Nur zwei Bits werden verwendet
  • Das Verhalten ist klar definiert und einfach zu implementieren
  • Unerwartetes Verhalten wird minimiert
  • Die Spezifikation lässt Raum für zukünftige Erweiterungen

3.9. Verhältnis zu anderen Mechanismen​

ECN ist komplementär zu anderen Mechanismen:

3.9.1. Differentiated Services (DiffServ)​

  • ECN kann mit DiffServ koexistieren
  • Die ECN-Bits sind unabhängig vom DSCP-Feld
  • Per-Hop-Behaviors (PHBs) können ECN-bewusst sein

3.9.2. Integrated Services (IntServ)​

  • ECN kann in IntServ-Umgebungen verwendet werden
  • RSVP-Signalisierung ist unabhängig von ECN
  • Ressourcenreservierung beeinflusst ECN-Verhalten nicht direkt

3.9.3. Multiprotocol Label Switching (MPLS)​

  • ECN kann über MPLS-Netzwerke transportiert werden
  • Spezifische Mechanismen für ECN über MPLS sind in separaten Dokumenten definiert

3.10. Keine Unterstützung für Multicast​

Diese Spezifikation behandelt nur Unicast-Verkehr. Die Verwendung von ECN mit Multicast erfordert zusätzliche Überlegungen und ist nicht Gegenstand dieses Dokuments.

3.11. Versionsneutralität (Version Neutrality)​

ECN ist für sowohl IPv4 als auch IPv6 definiert. Die Mechanismen sind im Wesentlichen identisch, mit nur geringfügigen Unterschieden in der Feldplatzierung innerhalb des IP-Headers.

Letztes Update am