Computing-Aware Traffic Steering Q. Li Internet-Draft Z. Luan Intended status: Informational Z. Fan Expires: 27 February 2027 Pengcheng Laboratory Y. Jiang Tsinghua SIGS / Pengcheng Laboratory 26 August 2026 A Timescale-Aware Framework for Compute-Aware Task Placement and Traffic Steering in Heterogeneous Geo-Distributed Computing Networks draft-luan-cats-catpts-01 Abstract 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. Status of This Memo 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/. Li, et al. Expires 27 February 2027 [Page 1] Internet-Draft Timescale-Aware CATPTS August 2026 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 Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Source-Compute-Destination Communication . . . . . . . . 6 3.2. Coupled Resources . . . . . . . . . . . . . . . . . . . . 6 3.3. Failure Exposure . . . . . . . . . . . . . . . . . . . . 6 3.4. Timescale Separation . . . . . . . . . . . . . . . . . . 6 4. Architectural Framework . . . . . . . . . . . . . . . . . . . 7 4.1. Functional Components . . . . . . . . . . . . . . . . . . 7 4.2. Logical Architecture . . . . . . . . . . . . . . . . . . 7 4.3. Relationship to CATS . . . . . . . . . . . . . . . . . . 8 5. Information Model . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Task Information . . . . . . . . . . . . . . . . . . . . 8 5.2. Compute Information . . . . . . . . . . . . . . . . . . . 9 5.3. Network and Path Information . . . . . . . . . . . . . . 9 5.4. Failure and Risk Information . . . . . . . . . . . . . . 9 6. Timescale-Aware Decision Process . . . . . . . . . . . . . . 10 6.1. Slow-Timescale Placement . . . . . . . . . . . . . . . . 10 6.2. Fast-Timescale Traffic Allocation . . . . . . . . . . . . 10 6.3. Triggering Rules . . . . . . . . . . . . . . . . . . . . 11 6.4. Consistency and Failure Handling . . . . . . . . . . . . 12 7. Risk-Aware Service-Loss Control . . . . . . . . . . . . . . . 12 7.1. Scenario Service Loss . . . . . . . . . . . . . . . . . . 12 Li, et al. Expires 27 February 2027 [Page 2] Internet-Draft Timescale-Aware CATPTS August 2026 7.2. CVaR Policy . . . . . . . . . . . . . . . . . . . . . . . 12 7.3. Proxy and Final Budgets . . . . . . . . . . . . . . . . . 12 7.4. Correlated Failures . . . . . . . . . . . . . . . . . . . 13 8. Abstract Optimization Model . . . . . . . . . . . . . . . . . 13 9. Framework Requirements and Invariants . . . . . . . . . . . . 14 10. Operational Considerations . . . . . . . . . . . . . . . . . 14 10.1. Telemetry Freshness and Hysteresis . . . . . . . . . . . 14 10.2. Admission Control and Infeasibility . . . . . . . . . . 14 10.3. Proxy Calibration . . . . . . . . . . . . . . . . . . . 15 10.4. Multi-Domain Deployment . . . . . . . . . . . . . . . . 15 10.5. Evaluation Guidance . . . . . . . . . . . . . . . . . . 15 11. Security and Privacy Considerations . . . . . . . . . . . . . 15 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 13. Manageability Considerations . . . . . . . . . . . . . . . . 16 14. Evolution from draft-luan-cats-catpts-00 . . . . . . . . . . 16 15. Normative References . . . . . . . . . . . . . . . . . . . . 17 16. Informative References . . . . . . . . . . . . . . . . . . . 17 Example Decision Walkthrough . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. 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 [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. Li, et al. Expires 27 February 2027 [Page 3] Internet-Draft Timescale-Aware CATPTS August 2026 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. 1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. 1.2. 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. Li, et al. Expires 27 February 2027 [Page 4] Internet-Draft Timescale-Aware CATPTS August 2026 2. Terminology +=================+==============================================+ | Term | Definition | +=================+==============================================+ | Task | A schedulable unit that requires compute | | | resources and generates an input stage and | | | an output stage. | +-----------------+----------------------------------------------+ | Compute-Capable | A node or service site able to execute a | | Node (CCN) | task and expose abstracted multi-dimensional | | | capacity and availability information. | +-----------------+----------------------------------------------+ | Candidate | The CCNs eligible for a task after | | Execution Set | 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 | The slow-timescale function that selects an | | Decision | execution node. | | Function (PDF) | | +-----------------+----------------------------------------------+ | Traffic | The fast-timescale function that refines | | Allocation | path allocation with placement fixed. | | Function (TAF) | | +-----------------+----------------------------------------------+ | Path Proxy | An estimate of network load and risk used by | | | the PDF without optimizing path-level split | | | variables. | +-----------------+----------------------------------------------+ | Failure | A modeled combination of available/ | | Scenario | 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 | An operator limit on a tail-risk measure, | | Budget | such as CVaR at a configured confidence | | | level. | +-----------------+----------------------------------------------+ Li, et al. Expires 27 February 2027 [Page 5] Internet-Draft Timescale-Aware CATPTS August 2026 Table 1: Terminology 3. Problem Statement 3.1. 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. Input stage Output stage Source ----------------> Selected CCN ----------------> Destination one or more paths one or more paths Figure 1: Source-Compute-Destination Communication 3.2. Coupled Resources 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. 3.3. Failure Exposure 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. 3.4. Timescale Separation 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 Li, et al. Expires 27 February 2027 [Page 6] Internet-Draft Timescale-Aware CATPTS August 2026 computationally expensive and operationally unstable. The framework separates the decisions while preserving their coordination. 4. Architectural Framework 4.1. Functional Components +=================+==========================================+ | Component | Responsibilities | +=================+==========================================+ | Task Intake and | Normalizes task requirements; applies | | Policy Function | locality, trust, sovereignty, affinity, | | | and eligibility policies. | +-----------------+------------------------------------------+ | Compute-State | Obtains capacity, utilization, | | Collector | capability, availability, and freshness | | | information from candidate sites. | +-----------------+------------------------------------------+ | Network-State | Obtains topology, capacity, utilization, | | and Path | path candidates, shared-risk | | Function | information, and path availability. | +-----------------+------------------------------------------+ | Scenario and | Builds or imports failure scenarios, | | Risk Function | weights, confidence level, and tail-risk | | | budget. | +-----------------+------------------------------------------+ | Placement | Chooses an execution node using compute | | Decision | load, path proxies, and risk screening. | | Function | | +-----------------+------------------------------------------+ | Traffic | Optimizes or selects input/output paths | | Allocation | with placement fixed and installs the | | Function | resulting policy. | +-----------------+------------------------------------------+ | Telemetry and | Validates realization, detects stale | | Assurance | state or violations, and triggers fast | | Function | refinement or slow replanning. | +-----------------+------------------------------------------+ Table 2: Functional Components 4.2. Logical Architecture Li, et al. Expires 27 February 2027 [Page 7] Internet-Draft Timescale-Aware CATPTS August 2026 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 Figure 2: Logical Architecture 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. 4.3. Relationship to CATS 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. 5. Information Model 5.1. Task Information * Task identifier and service identifier. * Source and destination identifiers or attachment points. Li, et al. Expires 27 February 2027 [Page 8] Internet-Draft Timescale-Aware CATPTS August 2026 * 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. 5.2. 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. 5.3. 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. 5.4. 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. Li, et al. Expires 27 February 2027 [Page 9] Internet-Draft Timescale-Aware CATPTS August 2026 * 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. 6. Timescale-Aware Decision Process 6.1. 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. 6.2. 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. Li, et al. Expires 27 February 2027 [Page 10] Internet-Draft Timescale-Aware CATPTS August 2026 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. 6.3. Triggering Rules +========================+=======================================+ | Event | Recommended response | +========================+=======================================+ | Short-lived congestion | Invoke fast traffic refinement if | | or path failure | feasible paths remain. | +------------------------+---------------------------------------+ | Compute utilization | Continue current placement; | | drift within headroom | optionally refine traffic. | +------------------------+---------------------------------------+ | Loss of selected | Invoke slow placement immediately; | | compute node | use preplanned fallback if available. | +------------------------+---------------------------------------+ | Material candidate- | Invoke slow placement, then fast | | set, topology, policy, | refinement. | | or workload change | | +------------------------+---------------------------------------+ | Tail-risk violation | Tighten placement proxy budget, | | after refinement | reduce admitted load, or invoke slow | | | replacement. | +------------------------+---------------------------------------+ | Stale or inconsistent | Use conservative defaults; suppress | | telemetry | unstable reoptimization; alert | | | assurance function. | +------------------------+---------------------------------------+ Table 3: Recommended Responses to Events Li, et al. Expires 27 February 2027 [Page 11] Internet-Draft Timescale-Aware CATPTS August 2026 6.4. Consistency and Failure Handling 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. 7. Risk-Aware Service-Loss Control 7.1. Scenario Service Loss 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. 7.2. CVaR Policy 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 Figure 3 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. 7.3. Proxy and Final Budgets 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 Li, et al. Expires 27 February 2027 [Page 12] Internet-Draft Timescale-Aware CATPTS August 2026 when the deployment claims conformance to the configured tail-risk policy. 7.4. Correlated Failures 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. 8. Abstract Optimization Model 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 / | Input/output allocation on candidate paths p | | x-out_i,m,q | and q. | +--------------+-------------------------------------------------+ | U-node-max / | Maximum normalized compute-resource and link | | U-link-max | utilization. | +--------------+-------------------------------------------------+ | eta_m(s) / | Availability of node m or path p in scenario s. | | chi_p(s) | | +--------------+-------------------------------------------------+ | lambda | Trade-off between compute and network | | | utilization. | +--------------+-------------------------------------------------+ Table 4: Optimization Symbols 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. Li, et al. Expires 27 February 2027 [Page 13] Internet-Draft Timescale-Aware CATPTS August 2026 9. 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. 10. Operational Considerations 10.1. Telemetry Freshness and Hysteresis 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. 10.2. Admission Control and Infeasibility 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. Li, et al. Expires 27 February 2027 [Page 14] Internet-Draft Timescale-Aware CATPTS August 2026 10.3. Proxy Calibration 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. 10.4. Multi-Domain Deployment 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. 10.5. Evaluation Guidance 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. 11. 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. Li, et al. Expires 27 February 2027 [Page 15] Internet-Draft Timescale-Aware CATPTS August 2026 * 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 [I-D.wang-cats-security-considerations]. 12. IANA Considerations This document has no IANA actions. 13. Manageability Considerations 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. 14. Evolution from draft-luan-cats-catpts-00 +===================+==================+============================+ | Area | Revision -00 | Revision -01 | +===================+==================+============================+ | Decision | Single joint | Slow placement plus fast | | structure | conceptual model | traffic refinement | +-------------------+------------------+----------------------------+ | Traffic | Two-stage | Retained; explicitly | | model | multipath | source-compute-destination | +-------------------+------------------+----------------------------+ Li, et al. Expires 27 February 2027 [Page 16] Internet-Draft Timescale-Aware CATPTS August 2026 | Network | Optional | Required proxy awareness | | awareness in | weighted | and calibration | | placement | objective | | +-------------------+------------------+----------------------------+ | Failure | General | Scenario model for node/ | | treatment | operational | path failures | | | concern | | +-------------------+------------------+----------------------------+ | Risk control | Not defined | Optional CVaR tail-risk | | | | budget and proxy budget | +-------------------+------------------+----------------------------+ | Architecture | Global | Named logical functions, | | | coordinator | state flows, epochs, and | | | sketch | triggers | +-------------------+------------------+----------------------------+ | Operations | Brief | Freshness, hysteresis, | | | applicability/ | infeasibility, | | | security text | calibration, assurance | +-------------------+------------------+----------------------------+ | CATS | Working-group | Explicit mapping to CATS | | alignment | context only | Service Sites/Instances | | | | and steering | +-------------------+------------------+----------------------------+ Table 5: Changes from Revision -00 15. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 16. Informative References [I-D.ietf-cats-framework] Li, C., "A Framework for Computing-Aware Traffic Steering (CATS)", Work in Progress, Internet-Draft, draft-ietf- cats-framework-24, April 2026, . Li, et al. Expires 27 February 2027 [Page 17] Internet-Draft Timescale-Aware CATPTS August 2026 [I-D.ietf-cats-usecases-requirements] Yao, K., "Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements", Work in Progress, Internet-Draft, draft-ietf-cats-usecases-requirements-14, February 2026, . [I-D.ietf-cats-metric-definition] Du, Z., "Metric Definition for Computing-Aware Traffic Steering", Work in Progress, Internet-Draft, draft-ietf- cats-metric-definition-10, June 2026, . [I-D.wang-cats-security-considerations] "Security Considerations for Computing-Aware Traffic Steering", Work in Progress, Internet-Draft, draft-wang- cats-security-considerations-04, March 2026, . [RFC9522] Awduche, D., "Overview and Principles of Internet Traffic Engineering", RFC 9522, January 2024, . [ROCKAFELLAR] Rockafellar, R. T. and S. Uryasev, "Optimization of Conditional Value-at-Risk", Journal Journal of Risk, 2000, . [TIMESCALE-PAPER] Luan, Z., "Timescale-Aware Compute-Intensive Workload Scheduling across Geo-Distributed Data Centers", Status Manuscript, 2026. [CATPTS-00] Li, Q., Luan, Z., and Y. Jiang, "A Framework for Compute- Aware Task Placement and Traffic Steering in Heterogeneous Computing Networks", Work in Progress, Internet-Draft, draft-luan-cats-catpts-00, March 2026, . Li, et al. Expires 27 February 2027 [Page 18] Internet-Draft Timescale-Aware CATPTS August 2026 Example Decision Walkthrough 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. Authors' Addresses Qing Li Pengcheng Laboratory Shenzhen China Email: liq@pcl.ac.cn Zeyu Luan Pengcheng Laboratory Shenzhen China Email: luanzy@pcl.ac.cn Zhuochen Fan Pengcheng Laboratory Shenzhen China Email: fanzhch@pcl.ac.cn Yong Jiang Tsinghua SIGS / Pengcheng Laboratory Shenzhen China Email: jiangy@sz.tsinghua.edu.cn Li, et al. Expires 27 February 2027 [Page 19]