Summary

  • RFC 9599 beschreibt, wie eine explizite Überlastungsanzeige aus einem unteren Frame oder äußeren Tunnel-Header in IP weitergegeben wird, bevor dieser Header verschwindet.
  • Ein beobachtetes CE belegt den Zustand dieses Headers an diesem Messpunkt. Es benennt weder die markierende Queue noch beweist es Empfängerfeedback oder eine Lastsenkung beim Sender.

Am Tunnelausgang trägt ein Paket CE. Die Messung ist eindeutig. Die Aussage „dieser Tunnel war überlastet“ ist es nicht.

Die Markierung kann bereits im inneren Header angekommen sein. Eine Layer-2-Queue kann sie außen gesetzt haben. Der Decapsulator kann zwei Zustände zusammengeführt und den schwereren behalten haben. Reframing kann das Ereignis einem späteren IP-Paket zuordnen. Wenn die Bedeutung vom DSCP abhing, kann eine Domänengrenze die Bits erhalten und ihren Kontext entfernt haben.

RFC 9599 wurde im August 2024 als Teil von BCP 89 veröffentlicht. Die Aufgabe ist enger und wichtiger: Ein explizites Signal darf nicht verschwinden, nur weil ein kapselnder Header entfernt wird. Ein verworfener Frame nimmt das innere Paket automatisch mit. Eine Markierung tut das nicht. Ohne bewusste Übergabe läuft das Paket weiter, während die Warnung endet.

Damit gehört der Decapsulator zum Regelkreis. ECN-fähige Transportendpunkte allein reichen nicht. Jede Funktion, die das Signal zum Load Regulator zurückbringen muss, muss mitwirken. Ein ECN-PDU ist deshalb eine Eigenschaft des gesamten Feedbackpfads. Die Fähigkeit kann in Bits, Labels, Flow-State, Konfiguration oder einem gebundenen Control-Plane-Kontext liegen.

Vier Modi trennen die Wege. Feed-forward-and-up trägt das Signal im unteren Layer zum Ausgang, hebt es in IP und lässt es vom Ziel zurückmelden. Feed-up-and-forward markiert den eingekapselten IP-Header direkt. Feed-backward meldet innerhalb des Subnetzes zum Eingang zurück. Null setzt voraus, dass der untere Fabric keinen eigenen Engpass erzeugt.

Feed-backward kann eine geschlossene Insel regeln, erreicht aber die ursprüngliche IP-Quelle nicht direkt. Der Eingang drosselt, die Quelle sendet weiter, und die Queue wandert zur Grenze. Eine Rückmeldung an den Subnetzeingang ist kein Beleg für eine Reaktion der Anwendung.

Feed-up-and-forward hängt von Sichtbarkeit ab. Verschlüsselung, unbekannte Shims und tiefe Kapselung können den IP-Header verbergen. RFC 9599 begrenzt deshalb die Suche und verlangt eine sichere Alternative wie Drop. Keine Markierung kann „nicht sichtbar“ bedeuten, nicht „keine Überlastung“.

Im Feed-forward-and-up-Modus muss der Eingang wissen, dass der Ausgang das Signal nicht verschluckt. MPLS kann dafür eine domänenweite Konfigurationspflicht einsetzen. TRILL nutzt ein fehlersicheres kritisches Flag: Ein alter Ausgang verwirft den Frame, statt die Markierung lautlos zu entfernen.

Der Ausgang darf den äußeren Wert nicht blind nach innen kopieren. Er berechnet den ausgehenden Zustand aus beiden Headern. Ist innen Not-ECT und außen die schwerste Anzeige, muss das Paket verworfen werden. CE in Not-ECT wäre ein Signal, das der Transport nicht zu lesen versprochen hat. Bei zwei gültigen Schweregraden gewinnt der stärkere.

Auch der Eingang sollte die bisherige Überlastung nicht auf null setzen. Ein gemeinsamer Ausgangswert ermöglicht es, aus aggregierten inneren und äußeren Markierungsraten den im Tunnel hinzugekommenen Anteil zu schätzen.

Schätzung ist kein Herkunftszertifikat. Populationen, Sampling und Randregeln müssen zusammenpassen. Beim Reframing sind zeitliche Nähe und Anteilserhaltung verschiedene Ziele. Eine Pipeline kann das Signal an ein etwas späteres IP-Paket heften. Das am Ende markierte Paket muss nicht dieselbe physische Einheit sein, die die Queue gesehen hat.

Die zwei Bits besitzen ohne Kontext auch keine einheitliche Semantik. Klassisches ECN, PCN und L4S können ECT(0), ECT(1) und CE unterschiedlich verwenden; teils hängt die Auslegung vom DSCP ab. Eine DSCP-Änderung kann Bits transportieren und Bedeutung verlieren.

Für Integrität muss ein unterwegs veränderbares Feld ausdrücklich als mutable gelten. Sonst zerstört eine legitime Markierung die Authentisierung eines vermeintlich unveränderlichen Headers. Und selbst bestätigtes Empfängerfeedback beweist keine Senderreaktion. Empfang und Wirkung sind getrennte Tatsachen.

Eine belastbare Abnahme bewahrt inneres ECN und DSCP am Eingang, Kapselungsregel, Tunnelidentität, Ausgangsfähigkeit, AQM-Konfiguration, innere und äußere Zustände am Ausgang, Weiterleitung oder Drop, Empfängerfeedback, Senderempfang und die gemessene Änderung von Rate oder Queue.

RFC 9599 macht das Signal transportierbar. Es macht seine Geschichte nicht selbstauthentisierend. Die Markierung bleibt Beweisstück; Herkunft, Verwahrung, Bedeutung und Wirkung müssen hinzukommen.

Sources