Zusammenfassung

  • RFC 8084 definiert einen Circuit Breaker für einen bestimmten Flow oder ein Aggregat in einem gemessenen Ingress-/Egress-Bereich; die Überschreitung muss über mehrere Messintervalle bestehen.
  • Ein Trip belegt die konfigurierte Schutzreaktion, also das Beenden oder deutliche Reduzieren von Verkehr in diesem Bereich. Er belegt weder Ursache noch Ort noch Wirkung beim Nutzer noch eine erfolgte Wiederherstellung.

Im Störungsbetrieb ist die Versuchung groß, den Zeitpunkt einer Schutzaktion zugleich als Zeitpunkt der Erkenntnis zu behandeln. Ein Graph fällt, ein Alarm wird ausgelöst, Verkehr wird entfernt. Die Abläufe sind sichtbar, doch sie beantworten verschiedene Fragen. Die Aktion kann korrekt sein, obwohl die Fehlerursache noch offen ist; gerade dafür ist ein letzter Schutzmechanismus da.

RFC 8084 erschien im März 2017 als IETF Best Current Practice BCP 208 und nennt G. Fairhurst als Autor. Sie beschreibt den Network Transport Circuit Breaker als letzte Schutzschicht, nicht als normalen Ersatz für Congestion Control. Sein Gegenstand ist kein abstraktes „Netz“, sondern eine Messstrecke. Verkehr tritt über einen oder mehrere Ingress-Punkte ein und über einen oder mehrere Egress-Punkte aus. Innerhalb dieses Bereichs wird ein bestimmter Transport-Flow oder ein Aggregat erfasst. Ein konfigurierter Schwellenwert wird über Messintervalle betrachtet.

Erst wenn der exzessive Zustand mehrere Intervalle überdauert, soll der Breaker auslösen. Seine Reaktion nimmt Verkehr aus dem Messbereich: durch Beendigung oder durch eine erhebliche Ratenreduktion.

Das ergibt einen belastbaren, aber begrenzten Beleg. Das Messsystem kann für seinen eigenen Geltungsbereich aussagen, dass es die vorausgesetzte Persistenz erkannt und die festgelegte Reaktion ausgeführt hat. Werden Bereich, Aggregat, Schwellenwertversion, Intervallfolge und Aktion gespeichert, kann diese Aussage nachgeprüft werden. Mehr als diese Aussage wird durch sie nicht autorisiert.

Die RFC nennt mögliche Auslöser für anhaltend exzessive Überlastung: anomalen Verkehr, anderweitig genutzte Kapazität, Routingänderungen, einen fehlkonfigurierten Dienst, ein Netzgerät, einen Admission Controller oder einen Policer. Das sind mögliche Klassen, keine auf den einzelnen Alarm übertragene Schuldzuweisung. In vielen Fällen, sagt das Dokument, ist die Ursache an der Quelle nicht erkennbar. Eine Anwendung erfährt möglicherweise weder, dass der Breaker ausgelöst hat, noch wo im Netz dies geschehen ist.

Ein Trip lokalisiert deshalb keinen Engpass. Er sagt nicht, dass alle Flows auf einem gemeinsamen Pfad dieselbe Bedingung hatten, bestimmt keine freie Kapazität und misst keine Kundenerfahrung. Er beweist auch nicht das Versagen einer gewöhnlichen Regelung. Selbst eine nachfolgende Ratenabsenkung ist kein Wiederherstellungsbeleg: Der Breaker kann seinen sichtbaren Anteil drosseln, während die zugrunde liegende Bedingung fortbesteht oder sich verlagert.

Heng Lus Grundsatz der minimalen Anfangsspezifikation bietet hierfür eine klare sprachliche Prüfung. Einer laufenden Instanz ist nur die deterministische, lokal prüfbare Bedeutung zuzuschreiben, die sie tatsächlich trägt. Der Zähler belegt Zählerstand und Reaktion. Routing-Telemetrie belegt Routing, Konfigurationshistorie belegt Änderungen, ein Remote-System seinen Zustand und ein Dienst seine Wirkung. Eine größere Überschrift verbindet diese Nachweise nicht.

So wird der Trip weder bagatellisiert noch überhöht. Er ist der reproduzierbare Auftakt einer Untersuchung: erst Messrahmen und Reaktion, dann mit eigenständigen Belegen Ursache, Ort, Auswirkung und Wiederherstellung.

Quellen