Summary

  • RFC 10053 lets CATS select a client-facing service contact using network and computing information. That contact can handle one or more internal service instances, and the selection may not disclose which instance ultimately serves a request.
  • Contact metrics can aggregate information from several service instances; a CATS service-metric agent may also aggregate across contacts. A selected path or reassuring aggregate is therefore evidence about the steering surface, not a request-level receipt for backend execution or service quality.

The entrance can be visible while the service remains behind it

Picture a team running a live video-rendering session. The client sends work to a service identifier. A steering system sees two candidate sites: one has a shorter path, the other has more available compute. It picks a reachable service contact and forwards the request there. From the client’s point of view, that contact is the service entrance. It may be the component that processes the request itself, or the one that decides which internal instance will do so.

RFC 10053 gives these pieces different names for a reason. A service instance is the collection of running resources that follows the provider’s service logic. A service contact instance is a client-facing function that receives a request and can handle one or more service instances. It may dispatch work to one or more of them, much like a service load balancer. The RFC says that steering beyond this contact is hidden from both clients and CATS components.

That definition creates a practical limit on what “CATS selected the service” means. The CATS Path Selector, or C-PS, uses information shared by service and network metric agents to choose an egress CATS forwarder, potentially together with a service contact, and a path for the traffic. The choice is about where the request enters the provider’s service structure. It does not, by itself, identify the internal instance that performs the work.

Metrics have a scope, and that scope can widen

RFC 10053 explicitly warns that the selection may not reveal the actual service instance a client invokes, including in hierarchical or recursive arrangements. It says the contact’s metrics may therefore be aggregates from multiple service instances. Elsewhere, Section 4.2 allows a CATS Service Metric Agent to aggregate metrics for multiple service contact instances, keep them separately, or do both. Those are distinct aggregation points: one may combine backend-instance conditions behind a contact; another may combine contact-level conditions for distribution to selectors.

This is not a claim that aggregation makes a metric false. It means a number has a boundary. A contact-level average can be useful for choosing an entry point while saying little about the tail of a particular backend, the instance assigned to one request, or the result that request produced. Likewise, a site-level aggregate can support scalable steering without being a per-contact measurement. The RFC leaves deployment choices to the provider and does not prescribe one selection algorithm.

A CATS Traffic Classifier can keep packets for a service request on the selected contact. Section 4.4 describes contact-instance affinity: packets in a flow stay with the same contact and path to reduce reordering and unpredictable latency. That is a useful forwarding property, but it does not turn the contact into a transparent window on its internal dispatch. The framework does not define a record that links each CATS decision to the backend instance and outcome.

For example, imagine a contact that fronts several image-processing instances. If a workload shift leaves one instance slower than the rest, an aggregate contact metric could still look acceptable. CATS may continue to steer toward the contact; the RFC does not say that it will see the skew or identify which request experienced it. This is a possible consequence of the stated visibility boundary, not a reported deployment incident or a measured result.

The division is intentional. RFC 10053 says the service provider retains control of internal resources and service logic, and that how the provider structures its service is outside the framework’s scope. CATS is designed to combine network and computing awareness for traffic steering; it is not a specification for inspecting a provider’s backend scheduler. A network operator should not be asked to infer more than the signals expose, and the service provider cannot treat a selected contact as proof of an individual request’s outcome.

RFC 10054 extends the CATS problem statement and requirements, but this article’s question is narrower: what can be known after traffic reaches a selected contact? The answer depends on telemetry and records the provider chooses to expose outside the framework. The RFCs do not require a universal backend-dispatch API, request trace, or outcome receipt. A deployment may build those controls, but their presence must be established separately.

The evidence chain stops at the contact unless someone extends it

For an operations team, the distinction matters when a steering change appears to improve latency while an application team sees uneven outcomes. The route and selected contact can explain where packets were sent. They cannot, without additional provider evidence, settle which internal instance handled a request, whether that instance had a degraded dependency, or whether a response met the service’s own objective.

The right operational language is correspondingly precise: “CATS selected this contact using these metric scopes” is supportable from steering records. “This backend served the request successfully” requires service-side evidence. “The service improved” requires an outcome measure tied to the relevant request or cohort. These are separate assertions, even when they are eventually joined in one observability system.

RFC 10053 is an architectural framework and limits itself to one service provider. It leaves the exact path-selection algorithm and the provider’s internal service design open. That makes it useful as a map of the steering boundary, not as a promise that a selected contact exposes every decision behind it.

Sources and status