Pengcheng Laboratory

ShenzhenChinaliq@pcl.ac.cn

Pengcheng Laboratory

ShenzhenChinaluanzy@pcl.ac.cn

Pengcheng Laboratory

ShenzhenChinafanzhch@pcl.ac.cn

Tsinghua SIGS / Pengcheng Laboratory

ShenzhenChinajiangy@sz.tsinghua.edu.cn

Routing Computing-Aware Traffic Steering CATStask placementtraffic steeringCVaR Geographically distributed compute-intensive services require coordinated selection of execution sites and wide-area traffic paths. Placement changes slowly because service relocation may involve model loading, state migration, or execution-environment reconfiguration, while traffic splitting can be changed more frequently. This document evolves the CATPTS framework by defining a timescale-aware control architecture for source-compute-destination services. A slow-timescale placement function uses abstracted multipath and failure information to select a compute site. A fast-timescale traffic function then refines the input and output traffic allocations across candidate paths while holding placement fixed. The framework also introduces scenario-based service-loss estimation and an optional Conditional Value at Risk (CVaR) policy for limiting tail loss caused by compute-site or network-link failures. This document specifies architectural principles, information requirements, workflows, and operational considerations; it does not specify protocol extensions or a mandatory optimization algorithm.

Introduction Compute-intensive services such as AI inference, distributed analytics, and edge-cloud processing increasingly span multiple geographically distributed service sites. A request may originate at one site, execute at another site selected from several compute-capable candidates, and deliver its result to a third site. The selected execution site determines both compute-resource consumption and the input and output traffic allocations across network paths. Conversely, network capacity, traffic congestion, path diversity, and failure exposure affect which execution site is operationally suitable. The initial CATPTS framework described a joint model for task placement and two-stage multipath steering under bandwidth and multi-dimensional compute constraints. This revision retains that foundation and adds two operational observations. First, task placement and traffic steering normally operate at different timescales. Second, average performance alone can conceal rare but severe service loss under site and link failures. This document therefore defines a two-level framework. The Placement Decision Function (PDF) operates at the slow timescale and selects an execution site using compute resource state, network abstractions, and risk policy. The Traffic Allocation Function (TAF) operates at the fast timescale and adjusts traffic allocations without relocating the task. Operators may use an equal-splitting path proxy at the placement level to avoid path-level decision variables, followed by non-uniform multipath refinement at the traffic level. Other conservative proxy methods are permitted. The framework is compatible with the functional decomposition and terminology of the CATS framework , its use cases and requirements , and the related metric definitions . It applies established traffic-engineering principles while extending the decision scope from steering a service flow toward a selected service instance to coordinating an explicit source-compute-destination task with input and output communication stages. It is an architectural and informational document and does not define signaling encodings, forwarding behavior, or interoperability requirements.

Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.

Scope and Non-Goals

• In scope: architectural functions, input information, two-timescale workflows, failure scenarios, tail-risk policy, and operational safeguards.
• Out of scope: a mandatory optimizer, metric advertisement protocol, service discovery protocol, path-programming protocol, or data-plane encapsulation.
• Out of scope: scheduling inside a single compute cluster and application-specific migration procedures.

Terminology Terminology

Term	Definition
Task	A schedulable unit that requires compute resources and generates an input stage and an output stage.
Compute-Capable Node (CCN)	A node or service site able to execute a task and expose abstracted multi-dimensional capacity and availability information.
Candidate Execution Set	The CCNs eligible for a task after capability, policy, trust, locality, and reachability filtering.
Input Stage	Traffic from the task source node to the selected execution node.
Output Stage	Traffic from the selected execution node to the task destination node.
Placement Decision Function (PDF)	The slow-timescale function that selects an execution node.
Traffic Allocation Function (TAF)	The fast-timescale function that refines path allocation with placement fixed.
Path Proxy	An estimate of network load and risk used by the PDF without optimizing path-level split variables.
Failure Scenario	A modeled combination of available/unavailable compute nodes and network paths, with an associated occurrence probability or operator weight.
Service Loss	The fraction or weighted amount of task traffic or task service not deliverable in a failure scenario.
Tail-Risk Budget	An operator limit on a tail-risk measure, such as CVaR at a configured confidence level.

Problem Statement

Source-Compute-Destination Communication For each task, the scheduler selects exactly one eligible execution node. Input traffic is carried from the source node to that execution node, and output traffic is carried from that execution node to the destination node. Either stage may use one or more candidate paths. This differs from conventional traffic engineering because the intermediate execution node is itself a decision variable.

Source-Compute-Destination Communication Selected CCN ----------------> Destination one or more paths one or more paths ]]>

Coupled ResourcesA placement decision consumes a vector of compute resources, for example GPU, CPU, high-bandwidth memory (HBM), and local storage. The two communication stages consume link bandwidth resource. Feasibility and performance therefore depend on both resources. Compute-only placement may overload a WAN bottleneck link; network-only steering cannot correct a poor execution-site choice.

Failure ExposureA compute-site failure interrupts tasks placed at that site and both associated input and output traffic. A link failure may interrupt multiple candidate paths and can create correlated loss when the paths share links. A scheduler that minimizes only expected loss can select a configuration with acceptable mean behavior but unacceptable low-probability impact. Operators therefore require a way to bound tail service loss independently from the normal-state utilization objective.

Timescale SeparationChanging an execution node may require state migration, model loading, cache warming, or environment reconfiguration. Placement is consequently a slow and potentially disruptive operation. Traffic splitting can often be changed through existing TE mechanisms with lower cost and at a faster cadence. Solving both placement and path allocation as one mixed-integer problem at every network event can be computationally expensive and operationally unstable. The framework separates the decisions while preserving their coordination.

Architectural Framework

Functional Components Functional Components

Component	Responsibilities
Task Intake and Policy Function	Normalizes task requirements; applies locality, trust, sovereignty, affinity, and eligibility policies.
Compute-State Collector	Obtains capacity, utilization, capability, availability, and freshness information from candidate sites.
Network-State and Path Function	Obtains topology, capacity, utilization, path candidates, shared-risk information, and path availability.
Scenario and Risk Function	Builds or imports failure scenarios, weights, confidence level, and tail-risk budget.
Placement Decision Function	Chooses an execution node using compute load, path proxies, and risk screening.
Traffic Allocation Function	Optimizes or selects input/output paths with placement fixed and installs the resulting policy.
Telemetry and Assurance Function	Validates realization, detects stale state or violations, and triggers fast refinement or slow replanning.

Logical Architecture

Logical Architecture +-------------------------------------+ | Traffic Allocation Function | Risk Policy ----------> | (fast input/output refinement) | +-------------------+-----------------+ | steering policy v Network and CCNs ^ | Telemetry / Assurance ]]>

The components are logical. They may be implemented in one controller or distributed across CATS components, a PCE, SDN controllers, cloud schedulers, and site-local agents. Administrative boundaries may require abstracted information rather than raw topology or capacity.

Relationship to CATSThe CATS framework defines components that collect service and network information and select service instances and paths. CATPTS can consume those abstractions. A CCN may correspond to a CATS Service Site and the executable target to a Service Instance. The CATPTS Placement Decision Function performs a task-level selection that also accounts for the input/output stage and multi-dimensional resource demand. The Traffic Allocation Function can use CATS-compatible steering policies or other TE mechanisms. No change to the base CATS data plane is required by this document.

Information Model

Task Information

• Task identifier and service identifier.
• Source and destination identifiers or attachment points.
• Compute-demand vector and required capabilities.
• Input and output traffic demand, optionally including latency, loss, or deadline objectives.
• Candidate execution set or constraints from which it can be derived.
• Priority, preemption class, lifetime, and placement stability preference.

Compute Information

• Resource dimensions, normalized capacity, available capacity, and utilization.
• Service capabilities, accelerator type, software or model availability, and readiness.
• Site/node availability and optional failure-domain identifier.
• Timestamp, validity interval, aggregation method, and confidence or quality indicator.

Network and Path Information

• Link or abstract-path capacity, measured/estimated load, latency, and administrative cost.
• Candidate paths for each source-to-CCN and CCN-to-destination pair.
• Path bottleneck capacity and path-link incidence when available.
• Shared-risk or correlation information sufficient to avoid treating overlapping paths as independent.
• State timestamp and validity interval.

Failure and Risk Information

• Scenario identifier and operator-assigned probability or normalized weight.
• Unavailable compute nodes, links, paths, or shared-risk groups in each scenario.
• Service-loss definition and per-task importance weight.
• Tail confidence level beta and risk budget Gamma.
• Placement-layer proxy budget Gamma-P, which may be stricter than the final budget to compensate for proxy error.

Implementations SHOULD expose the provenance and age of scenario data. Probabilities inferred from sparse history MUST NOT be presented as precise forecasts without a confidence indicator.

Timescale-Aware Decision Process

Slow-Timescale Placement

1. Filter candidate nodes using capability, policy, trust, locality, and basic reachability constraints.
2. Obtain a snapshot of compute, network, path, and risk information with a consistent decision epoch.
3. For each task-node mapping, construct a conservative path proxy for the input and output stages. Equal splitting among eligible candidate paths is one permitted proxy.
4. Estimate compute utilization, proxy link utilization, and scenario service loss for candidate placements.
5. Select one execution node per task while respecting compute capacity, proxy network limits, and the placement-layer risk budget.
6. Commit placement and pass the selected node plus candidate path sets to the Traffic Allocation Function.

The equal-splitting proxy is a planning abstraction, not a forwarding requirement. It removes fine-grained path variables from the placement search while retaining awareness of likely link load and failure exposure. An implementation MAY use another conservative abstraction if its error and operational behavior are understood.

Fast-Timescale Traffic Allocation

7. Hold the selected execution node fixed.
8. Refresh network state and remove unavailable or policy-ineligible paths.
9. Select non-uniform input and output path allocations that meet traffic demand and link capacity constraints.
10. Recompute scenario service loss and verify the final tail-risk budget.
11. Install the steering policy through an available mechanism and verify its realization.

Because placement is fixed, the fast problem contains continuous allocations or a bounded policy selection rather than a combined placement-and-routing search. Implementations SHOULD prefer stable updates and MAY impose rate limits, minimum-hold timers, or split-change penalties.

Triggering RulesRecommended Responses to Events

Event	Recommended response
Short-lived congestion or path failure	Invoke fast traffic refinement if feasible paths remain.
Compute utilization drift within headroom	Continue current placement; optionally refine traffic.
Loss of selected compute node	Invoke slow placement immediately; use preplanned fallback if available.
Material candidate-set, topology, policy, or workload change	Invoke slow placement, then fast refinement.
Tail-risk violation after refinement	Tighten placement proxy budget, reduce admitted load, or invoke slow replacement.
Stale or inconsistent telemetry	Use conservative defaults; suppress unstable reoptimization; alert assurance function.

Consistency and Failure HandlingA decision SHOULD carry an epoch or version covering the task set, placement, path set, and state snapshot. The Traffic Allocation Function MUST NOT install a policy for a superseded placement. Updates SHOULD be transactional where the deployment mechanism permits. If installation partially fails, the system SHOULD retain or restore a known-safe policy and report the realized state to the assurance function.

Risk-Aware Service-Loss Control

Scenario Service LossFor scenario s, service loss l_s represents the weighted task service that cannot be completed because its selected compute node is unavailable or because allocated traffic traverses unavailable paths. The exact unit is deployment-specific, but it MUST be consistent across scenarios and decision levels. Examples include lost traffic fraction, unserved task fraction, or priority-weighted unserved demand.

CVaR PolicyFor confidence level beta in (0,1), CVaR_beta(L) is the expected loss in the worst (1-beta) tail of the loss distribution. An equivalent linear form uses a threshold alpha and non-negative excess variables u_s:

= l_s - alpha, u_s >= 0 policy constraint: CVaR_beta(L) <= Gamma ]]>

CVaR is OPTIONAL. When used, beta, Gamma, loss units, scenario construction, and weighting policy MUST be configured together. A higher beta focuses on a smaller and more severe tail. Gamma is an operational risk appetite, not a reliability guarantee.

Proxy and Final BudgetsThe placement-layer path proxy can overestimate or underestimate the loss achievable after traffic refinement. Operators MAY configure a placement-layer budget Gamma-P distinct from the final budget Gamma. Gamma-P SHOULD be calibrated from observed proxy error and SHOULD be tightened when lower-level infeasibility or risk violations become frequent. The final installed policy MUST be checked against Gamma when the deployment claims conformance to the configured tail-risk policy.

Correlated FailuresCandidate paths that share a link, conduit, site, or regional dependency are not independent. Scenario generation SHOULD capture shared-risk groups where such information exists. Treating correlated failures as independent can materially understate tail risk. The framework does not require disclosure of sensitive physical topology; an operator may provide abstract correlation identifiers or conservative compound scenarios.

Abstract Optimization Model This section is informative and illustrates the decision semantics. It does not require a particular solver. Optimization Symbols

Symbol	Meaning
y_i,m	Binary placement of task i at candidate node m.
x-in_i,m,p / x-out_i,m,q	Input/output allocation on candidate paths p and q.
U-node-max / U-link-max	Maximum normalized compute-resource and link utilization.
eta_m(s) / chi_p(s)	Availability of node m or path p in scenario s.
lambda	Trade-off between compute and network utilization.

A single-level benchmark jointly chooses y and x to minimize lambda*U-node-max + (1-lambda)*U-link-max subject to unique placement, compute capacity, traffic demand, path activation, link capacity, scenario-loss, and CVaR constraints. The slow level chooses y using proxy traffic. The fast level fixes y and chooses x, normally minimizing U-link-max while retaining capacity and risk constraints. An implementation may use heuristics, decomposition, admission control, or policy search provided it preserves the architectural invariants in .

Framework Requirements and Invariants

• Exactly one active execution node MUST be selected for each admitted non-replicated task.
• Traffic allocated to an unselected execution node MUST be zero.
• Both input and output stages MUST be considered when assessing network feasibility.
• Compute and link capacity safety margins SHOULD be applied before advertised capacity is exhausted.
• A fast-timescale update MUST preserve the current placement unless it explicitly escalates to the slow-timescale process.
• Risk evaluation MUST use the same placement and traffic policy that is intended for installation.
• Candidate eligibility and trust policy MUST take precedence over utilization optimization.

Operational Considerations

Telemetry Freshness and HysteresisCompute and network telemetry may have different collection intervals and delays. Controllers SHOULD record timestamps and reject combinations whose skew exceeds an operator-defined bound. Hysteresis, minimum-hold timers, and improvement thresholds SHOULD be used to reduce oscillation. The slow placement cadence SHOULD normally be longer than the fast traffic cadence.

Admission Control and InfeasibilityA request may be infeasible because no candidate node satisfies compute, network, policy, and risk constraints simultaneously. The controller SHOULD return a reason category and MAY apply operator policy such as queueing, demand reduction, degraded service, replication, or rejection. It MUST NOT silently violate a mandatory trust or locality constraint.

Proxy CalibrationOperators SHOULD monitor the difference between placement-level proxy estimates and final traffic-allocation results. Useful indicators include lower-level feasibility rate, final-to-proxy utilization gap, final CVaR, reoptimization frequency, and placement churn. Persistent bias indicates that the path set, proxy rule, or Gamma-P requires adjustment.

Multi-Domain DeploymentAdministrative domains may expose only abstract capacity, path, and reliability information. The framework can operate on such abstractions, but their aggregation method, validity interval, and conservative margin SHOULD be stated. Cross-domain optimization MUST respect data-sharing and policy boundaries. This document does not define inter-domain signaling.

Evaluation GuidanceImplementations should report scale along at least four dimensions: number of tasks, candidate execution nodes, candidate paths per stage, and failure scenarios. They should also report decision time, admitted load, maximum compute and link utilization, tail-risk value, lower-level feasibility, and placement churn. The study motivating this revision found that a two-level method remained close to the single-level benchmark while substantially reducing solve time; those results are evidence for the architecture, not protocol requirements or universal performance guarantees.

Security and Privacy Considerations CATPTS decisions depend on compute advertisements, network telemetry, topology abstractions, and failure statistics. Manipulation of any of these inputs can steer tasks toward an overloaded, malicious, or inappropriate site; cause denial of service; or expose sensitive workload information.

• Information sources and controller-to-agent channels MUST be authenticated and integrity protected.
• Authorization MUST limit which entities may advertise compute capacity, change risk policy, request placement, or install steering state.
• Implementations SHOULD validate ranges, freshness, monotonic counters, and cross-source consistency, and SHOULD quarantine implausible advertisements.
• Raw task metadata, topology, site capacity, and failure history can reveal commercially or operationally sensitive information. Collection and retention SHOULD be minimized, and abstractions SHOULD be used across trust boundaries.
• A malicious tenant can misstate compute or traffic demand to obtain favorable placement or exhaust resources. Admission control, quotas, accounting, and post-placement measurement SHOULD be applied.
• Frequent reoptimization can itself become an attack surface. Controllers SHOULD rate-limit triggers, apply hysteresis, and maintain a known-safe fallback policy.
• Scenario weights derived from history can encode bias or be poisoned. Provenance, bounded update rates, and operator review SHOULD be used for material risk-policy changes.

This framework does not remove the security requirements of the protocols used for metric distribution, controller communication, or steering installation. Additional CATS-specific threats and mitigations are discussed in .

IANA ConsiderationsThis document has no IANA actions.

Manageability ConsiderationsAn implementation SHOULD expose: current placement and epoch; installed input/output steering policy; data freshness; proxy and final utilization; configured beta, Gamma, and Gamma-P; final risk result; trigger cause; solver or decision status; fallback state; and audit records for policy changes. Alerts SHOULD distinguish telemetry failure, placement infeasibility, installation failure, and tail-risk violation.

Evolution from draft-luan-cats-catpts-00Changes from Revision -00

Area	Revision -00	Revision -01
Decision structure	Single joint conceptual model	Slow placement plus fast traffic refinement
Traffic model	Two-stage multipath	Retained; explicitly source-compute-destination
Network awareness in placement	Optional weighted objective	Required proxy awareness and calibration
Failure treatment	General operational concern	Scenario model for node/path failures
Risk control	Not defined	Optional CVaR tail-risk budget and proxy budget
Architecture	Global coordinator sketch	Named logical functions, state flows, epochs, and triggers
Operations	Brief applicability/security text	Freshness, hysteresis, infeasibility, calibration, assurance
CATS alignment	Working-group context only	Explicit mapping to CATS Service Sites/Instances and steering

Normative References Informative References

Example Decision WalkthroughA task originates at Hong Kong, may execute at Tokyo or Singapore, and delivers results to San Francisco. Both execution candidates satisfy compute requirements. The Placement Decision Function first estimates input and output link loads using equal splitting over four candidate paths per stage. A scenario set contains the normal state, selected link failures, and compute-site failures. The Singapore placement has lower normal compute load but exceeds Gamma-P because several paths share a high-risk conduit. Tokyo is selected. The Traffic Allocation Function then fixes Tokyo and shifts most input traffic to the more reliable path while balancing the output paths. It verifies that the final CVaR is at or below Gamma and installs the resulting steering policy. A later transient link failure triggers only traffic refinement; a Tokyo site failure escalates to slow placement.