Zusammenfassung

  • In draft-xiao-fann-fast-cnp-with-proxy-05 schickt der überlastete Knoten zunächst eine UDP-Nachricht an einen Proxy; dieser erzeugt daraus einen zweiten, für einen RoCEv2-Sender verständlichen CNP.
  • Der Standard-CNP kann richtig und nützlich sein, ohne die verwendete Flow/QP-Mapping-Version, den ursprünglichen Überlastungsknoten oder lokal verworfene Eingangsmeldungen offenzulegen.

Der Sender empfängt einen gewöhnlichen RoCEv2 Congestion Notification Packet und drosselt das betroffene Queue Pair. Aus seiner Sicht wirkt alles vertraut. Tatsächlich hat der überlastete Router ihm keinen Standard-CNP geschickt. Er sandte eine andere UDP-Nachricht an einen Proxy. Dort wurde aus beobachtetem Zustand ein Sender samt Source QP bestimmt und erst danach das Paket erzeugt, das am Host ankam.

Genau diese Übersetzung beschreibt Revision 05 von Fast Congestion Notification Packet with Proxy vom 29. September. Ein VPN-Provider-Router kann in einer anderen Routing-Domäne als der Sender liegen. Außerdem fehlt ihm womöglich die Source-QP-Information, die ein regulärer RoCEv2-CNP benötigt. Der Proxy überbrückt beides.

Er wird dadurch jedoch zu einer neuen Beweisgrenze. Das zweite Paket kann syntaktisch einwandfrei und operativ wirksam sein, obwohl es kaum erkennen lässt, wie die Zwischenentscheidung zustande kam.

Aus einem Ereignis werden zwei Pakete

Auf dem ersten Abschnitt sendet der Überlastungsknoten eine eigene Benachrichtigung an einen Proxy derselben kontrollierten Routing-Domäne. Auf dem zweiten erzeugt der Proxy ein Format, das der Verkehrssender bereits beherrscht. Revision 05 konzentriert sich dabei auf den Standardpfad für RoCEv2 und nimmt frühere, breitere Aussagen über beliebige Nicht-RoCE-Sender zurück.

Format 1 enthält das IP-Fünfertupel des Datenstroms und die 24 Bit lange Destination QP. Es geht an den vorgeschlagenen UDP-Port TBD1. Anhand der Quelladresse findet der Proxy den Sender; Protokoll und Zielport identifizieren RoCEv2. Für den ausgehenden Standard-CNP fehlt aber noch die Source QP. Sie wird aus einem Source-QP/Destination-QP-Mapping im Kontext der Quell- und Zieladressen ermittelt.

Dieses Mapping ist nicht bloß statische Konfiguration. Der gewählte Proxy muss Hin- und Rückverkehr von RoCEv2 sehen, um die Beziehung zu lernen. Die erste Meldung liefert die Destination QP, nicht eine fertig aufgelöste Source QP. Die Übersetzung hängt somit von gespeichertem Beobachtungszustand ab.

Format 2 transportiert neben dem Fünfertupel eine NRP Selector ID zum vorgeschlagenen Port TBD2. Bei RoCEv2 hilft der Selektor, die Source QP zu bestimmen; im VPN-Fall hilft er bei der Auswahl des VPN. Dafür braucht der Proxy Source-QP/NRP- beziehungsweise VPN-ID/NRP-Mappings. Der Selektor ist ein Suchschlüssel, kein Nachweis für die Aktualität der Tabelle.

Eine Fähigkeitsanzeige ist kein Zustandsbeleg

Der Überlastungsknoten muss zunächst wissen, welcher Proxy den Absenderpräfix bedient. Der Entwurf koppelt eine Proxy Node Capability, PNC, an die Präfixe angeschlossener Sender. Für IS-IS und OSPF sind P-Flags vorgesehen, für BGP ein vorgeschlagenes Next Hop Dependent Characteristic TLV mit der Proxy-Adresse.

Damit wird eine Routingfrage beantwortet: Welcher Knoten beansprucht, den Proxy-Dienst für dieses Präfix bereitzustellen? Offen bleibt, ob dieser Knoten beide Verkehrsrichtungen beobachtet, das richtige QP-Paar gelernt, die aktuelle NRP- oder VPN-Zuordnung behalten, noch Reserven im Rate-Limit hat, das erste Paket akzeptiert oder das zweite ausgeliefert hat.

Die Werbung kann unverändert bleiben, während ein gelerntes Mapping altert, verschoben wird oder kollidiert. Ein verbreitetes Capability-Bit ist kein Gesundheitstest für die dahinterliegende Datentabelle.

Der Proxy darf Hinweise absichtlich verwerfen

Im Normalfall soll auf jede erste Meldung eine zweite folgen. Der Text nennt aber sofort eine Ausnahme: Überschreitet die Empfangsfrequenz das lokale Limit des Proxys, darf er einen Teil der eingehenden Meldungen nach eigener Richtlinie verwerfen.

Das ist eine vernünftige Schutzmaßnahme. Eine Flut von Benachrichtigungen könnte die Kontrollfläche selbst überlasten. Der Sicherheitsabschnitt empfiehlt Rate-Limits und Grenzfilter, beschränkt das Verfahren auf eine kontrollierte Domäne und sieht es standardmäßig als deaktiviert vor.

Doch mit jedem Schutz-Drop verschwindet auch Information. Zehn Meldungen des Engpassknotens können zu drei CNPs für den Sender werden. Der Standard-CNP enthält weder die ursprüngliche Ereigniskennung noch Drop-Zähler, Entscheidungsgrund, Mapping-Version oder Identität des Engpassknotens. Der Sender kann auf die drei sichtbaren Signale reagieren, die sieben fehlenden aber nicht aus ihrem Schweigen rekonstruieren.

Dieses Schweigen hat viele mögliche Ursachen: kein Engpass, falscher oder veralteter PNC-Pfad, Mapping-Fehler, Grenzfilter, deaktivierte Funktion, Rate-Limit auf dem ersten Abschnitt oder Verlust auf dem zweiten. Das Paketformat unterscheidet sie nicht.

Ein brauchbarer CNP ist noch keine Quittung

Die übersetzte Anweisung ist deshalb nicht falsch. Sie kann genau das enthalten, was ein älterer Sender braucht: die Rate des rekonstruierten Source QP zu senken. Gerade weil am Endpunkt kein neues Eingangsformat implementiert werden muss, entsteht der Nutzen.

Problematisch wäre nur, Kompatibilität mit Herkunftsnachweis gleichzusetzen. UDP-Aufbau und Prüfsumme authentisieren das erste Ereignis nicht. Der CNP zeigt weder dessen Bytes noch den Eingangszeitpunkt beim Proxy. Er zählt nicht alle Ereignisse, lokalisiert den Engpass nicht und beweist nicht, dass die richtige Flow-Zuordnung verwendet wurde.

Betreiber brauchen daher eine verknüpfte Beweiskette. Am Engpass gehören Queue- und ECN-Zähler, Anzahl der ersten Meldungen und gewählter Proxy dazu. Im Routing muss die zum Ereigniszeitpunkt verwendete PNC-Route nachvollziehbar bleiben. Der Proxy sollte Mapping-Generation, Lernzeit, Annahmen, Verwerfungen, Übersetzungsgrund und ausgegebene CNPs protokollieren. Beim Sender zählen empfangene CNPs, QP-Reaktion und Ratenänderung. Unabhängige Messungen von Queue-Erholung, Abschlusszeit und Anwendungseffekt schließen die Kette.

Keiner dieser Datensätze reicht allein. Aussagekraft entsteht erst durch ihre Verbindung.

Revision 05 begrenzt auch den Reifeanspruch

Die neue Revision entfernt allgemeine Formulierungen zu beliebigen Nicht-RoCE-Sendern und beschreibt die Standardkonstruktion für RoCEv2 präziser. Sie stellt ausdrücklich klar, dass das Lernen der Source-QP/Destination-QP-Beziehung einen Proxy auf Hin- und Rückweg erfordert. Außerdem erwähnt sie als Implementierungsvariante ein ECN-markiertes Datenpaket als Proxy-Eingang, erklärt dieses Verfahren jedoch für nicht spezifiziert.

Das ist weder ein definierter dritter Nachrichtentyp noch ein Interoperabilitätsbericht. Das Dokument bleibt ein individueller Internet-Draft ohne Stream, zuständigen AD oder formalen IETF-Status. Ports, Routing-Bits und der BGP-Characteristic-Code sind weiterhin Vorschläge. Aus dem festgelegten Paket lässt sich keine reale Einführung, Leistung oder benannte konforme Implementierung ableiten.

Für Führungskräfte folgt daraus eine enge Aussage: Der Entwurf bietet einen plausiblen Kompatibilitätsmechanismus. Er verlagert aber Senderauswahl, Flow-Identität und Vollständigkeit der Meldungen in einen Proxy, dessen Entscheidungen im Standard-CNP unsichtbar bleiben. Soll dieses Paket automatisierte Eingriffe oder Vorfallzuordnung auslösen, braucht auch die Übersetzung eine beobachtbare Quittung.

Quellen