| Internet-Draft | Timescale-Aware CATPTS | August 2026 |
| Li, et al. | Expires 27 February 2027 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 27 February 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [CATPTS-00] 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 [I-D.ietf-cats-framework], its use cases and requirements [I-D.ietf-cats-usecases-requirements], and the related metric definitions [I-D.ietf-cats-metric-definition]. It applies established traffic-engineering principles [RFC9522] 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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.¶
| 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. |
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.¶
Input stage Output stage
Source ----------------> Selected CCN ----------------> Destination
one or more paths one or more paths
A 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.¶
A 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.¶
Changing 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.¶
| 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. |
Task/Policy ---------+ Compute State --------+
| |
v v
+------------------------------------------------+
| Placement Decision Function (slow) |
| site selection + proxy risk screening |
+-----------------------+------------------------+
| fixed placement
v
Network/Path State ---> +-------------------------------------+
| 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.¶
The 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.¶
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.¶
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.¶
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.¶
| 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. |
A 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.¶
For 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.¶
For 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 [ROCKAFELLAR] uses a threshold alpha and non-negative excess variables u_s:¶
minimize over alpha: alpha + 1/(1-beta) * SUM_s p_s u_s subject to: 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.¶
The 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.¶
Candidate 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.¶
This section is informative and illustrates the decision semantics. It does not require a particular solver.¶
| 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 Section 9.¶
Compute 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.¶
A 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.¶
Operators 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.¶
Administrative 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.¶
Implementations 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 [TIMESCALE-PAPER] 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.¶
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.¶
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 [I-D.wang-cats-security-considerations].¶
This document has no IANA actions.¶
An 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.¶
| 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 |
A 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.¶