Zusammenfassung

  • RFC 10053 lässt CATS anhand von Netz- und Recheninformationen einen clientseitig erreichbaren Servicekontakt auswählen. Ein Kontakt kann eine oder mehrere interne Serviceinstanzen bedienen; aus der Auswahl geht daher nicht hervor, welche Instanz eine Anfrage tatsächlich verarbeitet hat.
  • Die Metriken eines Kontakts können mehrere Serviceinstanzen zusammenfassen; ein Service-Metrikagent kann zusätzlich mehrere Kontakte aggregieren. Ein gewählter Pfad oder ein beruhigender Mittelwert belegt damit den Zustand der Steuerungsebene, aber weder die Ausführung einer einzelnen Anfrage noch deren Serviceergebnis.

Der Eingang ist sichtbar, die Verarbeitung dahinter nicht

Nehmen wir einen OCR-Dienst für eingehende Belege. Ein Client sendet einen Auftrag an eine Servicekennung. Die Steuerung vergleicht einen Standort mit kürzerem Netzpfad und einen zweiten mit mehr verfügbarer Rechenkapazität. Sie wählt einen erreichbaren Servicekontakt und leitet die Anfrage dorthin. Für den Client ist dieser Kontakt der Eingang zum Dienst. Er kann die Anfrage selbst verarbeiten oder entscheiden, welche interne Instanz sie übernimmt.

RFC 10053 unterscheidet diese Rollen bewusst. Eine Serviceinstanz ist eine Gruppe laufender Ressourcen, die nach der Dienstlogik des Anbieters zusammenarbeitet. Ein Servicekontakt ist eine clientseitige Funktion, die Anfragen entgegennimmt und eine oder mehrere Instanzen bedienen kann. Er kann die Arbeit intern verteilen, ähnlich einem Load Balancer. Laut RFC bleibt die Steuerung hinter dem Kontakt sowohl für Clients als auch für CATS-Komponenten verborgen.

Deshalb muss die Aussage „CATS hat den Dienst ausgewählt“ präzise bleiben. Der CATS Path Selector (C-PS) verwendet Informationen von Service- und Netz-Metrikagenten, um einen Egress-CATS-Forwarder, gegebenenfalls einen Servicekontakt und einen Pfad auszuwählen. Damit wird festgelegt, an welcher Stelle eine Anfrage in die Dienststruktur des Anbieters eintritt. Die interne Instanz, die die Arbeit erledigt, ist damit nicht automatisch identifiziert.

Metriken haben einen Umfang – und mehrere mögliche Aggregationsebenen

RFC 10053 weist ausdrücklich darauf hin, dass die Auswahl die tatsächlich aufgerufene Serviceinstanz möglicherweise nicht offenlegt, etwa bei hierarchischen oder rekursiven Strukturen. Deshalb können Kontaktmetriken Werte mehrerer Serviceinstanzen zusammenfassen. Abschnitt 4.2 erlaubt außerdem, dass ein CATS Service Metric Agent Metriken mehrerer Servicekontakte aggregiert, getrennt hält oder beides tut. Das sind zwei verschiedene Ebenen: Die eine kann Zustände interner Instanzen hinter einem Kontakt bündeln; die andere kann mehrere Kontakte zusammenfassen, bevor die Auswahlkomponenten ihre Daten erhalten.

Eine Aggregation macht die Metrik nicht falsch. Sie macht ihren Bezugsrahmen entscheidend. Ein Kontaktmittelwert kann bei der Wahl eines Einstiegspunkts helfen und zugleich wenig über besonders langsame Anfragen, die Instanz einer bestimmten Anfrage oder deren Ergebnis aussagen. Auch ein standortweiter Wert kann die Skalierung der Steuerung erleichtern, ohne eine Einzelmessung für jeden Kontakt zu sein. Die RFC überlässt Bereitstellungsentscheidungen dem Anbieter und schreibt keinen einzelnen Auswahlalgorithmus vor.

Der CATS Traffic Classifier kann Pakete einer Serviceanfrage beim ausgewählten Kontakt halten. Abschnitt 4.4 beschreibt die Affinität zu einer Servicekontaktinstanz: Pakete eines Flows bleiben am selben Kontakt und auf demselben Pfad, um Umordnung und unvorhersehbare Latenzschwankungen zu verringern. Das ist eine nützliche Weiterleitungseigenschaft, macht die interne Verteilung des Kontakts aber nicht sichtbar. Das Framework definiert kein Protokoll, das jede CATS-Auswahl mit der Backendinstanz und dem Ergebnis der Anfrage verbindet.

Angenommen, ein Kontakt verteilt OCR-Aufträge auf mehrere Erkennungsinstanzen. Wird eine davon nach einer Lastverschiebung langsamer, kann die aggregierte Kontaktmetrik dennoch unauffällig wirken. CATS könnte den Kontakt weiter auswählen, ohne die Schieflage oder die betroffenen Anfragen zu erkennen. Das ist eine mögliche Folge der beschriebenen Sichtbarkeitsgrenze, kein beobachteter Vorfall und kein Messergebnis eines bestimmten Betreibers.

Diese Trennung ist beabsichtigt. RFC 10053 hält fest, dass der Dienstanbieter die Kontrolle über interne Ressourcen und Dienstlogik behält; wie er seinen Dienst strukturiert, liegt außerhalb des CATS-Rahmens. CATS kombiniert Netz- und Rechenzustände für die Verkehrssteuerung, spezifiziert aber keine Prüfung des internen Backend-Schedulers. Der Netzbetreiber sollte nicht mehr aus den Signalen ableiten, als sie zeigen. Der Anbieter sollte einen ausgewählten Kontakt nicht als Nachweis dafür behandeln, dass eine bestimmte Anfrage erfolgreich war.

RFC 10054 erweitert die Problemstellung und Anforderungen von CATS. Hier geht es um eine engere Frage: Was lässt sich wissen, nachdem der Verkehr den ausgewählten Kontakt erreicht hat? Das hängt von Telemetrie und Aufzeichnungen ab, die der Anbieter zusätzlich offenlegt. Die RFCs verlangen weder eine allgemeine Backend-Dispatch-API noch Anfrage-Traces oder Ergebnisquittungen. Ein Einsatz kann solche Kontrollen ergänzen; ihr Vorhandensein muss separat nachgewiesen werden.

Ohne zusätzliche Belege endet die Spur am Kontakt

Der Unterschied zählt im Betrieb, wenn eine Steuerungsänderung die Latenz scheinbar senkt, das Anwendungsteam aber uneinheitliche Ergebnisse sieht. Pfad und gewählter Kontakt erklären, wohin Pakete gelangt sind. Ohne Belege des Anbieters zeigen sie nicht, welche interne Instanz eine Anfrage bearbeitet hat, ob eine beeinträchtigte Abhängigkeit beteiligt war oder ob die Antwort das Dienstziel erfüllte.

Ein sauberer Betriebsbericht kann sagen: „CATS wählte diesen Kontakt anhand dieser Metriken und dieses Bezugsrahmens.“ Für die Aussage „dieses Backend hat die Anfrage erfolgreich bedient“ braucht es einen Beleg aus dem Dienst. Für „der Dienst wurde besser“ braucht es ein Ergebnismaß, das zur relevanten Anfrage oder Gruppe gehört. Das sind verschiedene Aussagen, auch wenn ein Observability-System sie später zusammenführt.

RFC 10053 ist ein Architekturrahmen für einen einzelnen Dienstanbieter. Er legt weder den genauen Auswahlalgorithmus noch die interne Dienstarchitektur fest. Er markiert die Grenze der Verkehrssteuerung, verspricht aber nicht, dass ein ausgewählter Kontakt alle späteren Entscheidungen offenlegt.

Quellen und Geltungsbereich