Pengcheng Laboratory

Shenzhen China zhangb@pcl.ac.cn

Pengcheng Laboratory

Shenzhen China yangrw@pcl.ac.cn

RTG CATS CATS Computing-Aware Traffic Steering Service Metrics IANA Registry This document defines the initial set of registry entries for Computing Service Metrics used in Computing-Aware Traffic Steering (CATS). These metrics, including Global Available Slots (GAS), Computing Time, Cost, Reputation, Security Label, and Capability, provide service-oriented abstractions that complement the existing CATS Level 0/Level 1/Level 2 normalized metric framework defined in . This document follows the registry format and separation pattern established by and , populating a new IANA registry titled "CATS Computing Service Metrics" with formal entries for each metric defined in .

Introduction The Computing-Aware Traffic Steering (CATS) framework introduces a multi-level metric framework that organizes computing and communication metrics into three abstraction levels (Level 0, Level 1, and Level 2). While this framework provides a solid theoretical baseline, mapping diverse hardware capabilities into normalized scores is highly complex and provider-dependent. To bridge the gap between theoretical metric definitions and practical operational execution, defines a set of Computing Service Metrics. These metrics are service-oriented abstractions that describe the concrete ability of a service site to handle specific services, including Global Available Slots (GAS), Computing Time, Cost, Reputation, Security Label, and Capability. This document follows the pattern established by and : defines the format for the IANA Registry of Performance Metrics, while populates that registry with the initial set of entries. Similarly, establishes the CATS metric framework and registry structure, and this document populates the "CATS Computing Service Metrics" registry with the initial set of entries for Computing Service Metrics. The registry entries defined in this document provide the formal specification required for IANA assignment of identifiers, ensuring interoperability across CATS implementations that use these service-oriented metrics for traffic steering decisions.

Terminology This document makes use of the terms defined in and . In particular:

• CATS Service ID (CS-ID)
• CATS Service Contact Instance ID (CSCI-ID)
• CATS Service Metric Agent (C-SMA)
• CATS Path Selector (C-PS)

Additionally, the following terms are used as defined in :

• Global Available Slots (GAS)
• Computing Time
• Cost
• Reputation
• Security Label
• Capability

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, as shown here.

Registry Structure This document defines entries for the "CATS Computing Service Metrics" registry. Each registry entry follows the structure defined in Section 6, which aligns with the Performance Metrics Registry format specified in . Each registry entry contains the following top-level categories:

• Summary: Includes the element ID, Metric Name, URI, Metric Description, Metric Change Controller, and Metric Version.
• Metric Definition: Includes the Reference Definition and Fixed Parameters.
• Method of Measurement: Includes Reference Methods, Packet Stream Generation, Traffic Filtering Details, Sampling Distribution, Runtime Parameters and Data Format, and Roles.
• Output: Includes Type, Reference Definition, Metric Units, and Calibration.
• Administrative Items: Includes Status, Requester, Revision, Revision Date, and Comments and Remarks.

The naming convention for Computing Service Metrics follows the pattern:

__CATS-Service__RFCXXXXsecY__

]]>

Where:

• Type: "Svc" for Service-oriented metric.
• Method: "Passive" for metrics derived from local monitoring and estimation (all Computing Service Metrics are passive).
• Name: The metric name (e.g., GAS, ComputingTime).
• RFCXXXXsecY: The RFC number and section reference (to be assigned).
• Unit: The metric unit (e.g., Count, Milliseconds, Unitless).
• Output: "Singleton" for single-valued metrics.

CATS Computing Service Metric Registry Entries This section defines the formal registry entries for the initial set of Computing Service Metrics. These metrics are divided into Mandatory Metrics (Section 4.1 and Section 4.2) and Optional Extension Metrics (Section 4.3 through Section 4.6), consistent with the classification in .

Global Available Slots (GAS)

Summary

ID (Identifier) IANA has allocated the Identifier TBD1 for this Named Metric Entry. See for the mapping to Names.

Name Svc_Passive_CATS-Service_GAS_RFCXXXXsecY_Count_Singleton

URI To-be-assigned.

Description Global Available Slots (GAS) represents the maximum number of concurrent clients that a service site is willing and able to serve for a specific CS-ID through a specific CSCI-ID at a given time. GAS acts as a direct abstraction layer over complex and fluctuating raw computing metrics (CPU, GPU, Memory, Storage) and status metrics (load and health). Instead of exposing highly dynamic raw metrics to the network, the service site absorbs these variations internally and reports a single, actionable capacity indicator. As the number of concurrent users increases, the GAS value naturally decreases. The site monitoring system dynamically reduces the GAS value upon detecting abnormal status metrics, such as load changes, health changes, or reachability issues. When GAS drops to 0, the instance cannot allocate any more resources, and no new requests will be steered to it.

Change Controller IETF

Version 1.0

Metric Definition

Reference Definition Core referenced sections: Section 4.2.1 (Global Available Slots)

Fixed Parameters

• Metric type: "gas"
• Level: Service-oriented (L0/TBD)
• Data type: non-negative integer
• Metric units: Count (number of concurrent client slots)
• Initial value: Derived from service reference information and local resource allocation

Method of Measurement

Reference Methods GAS is derived from basic resource metrics, status metrics, service requirements, and local policy at the service site. The specific derivation algorithm is a local matter and is not standardized by this document. However, the following reference method is provided as an example:

Where:

• max_capacity_i is the maximum concurrent request capacity of instance i, derived from resource allocation and reference GAS information.
• active_sessions_i is the current active session count of instance i.
• Only healthy instances contribute to the GAS calculation; unhealthy instances contribute 0.

The Metric Aggregator (MA) MAY apply a local policy factor (e.g., a safety margin of 80%) to prevent over-subscription. The service site can initially provide a GAS value based on its fixed resource allocation and service reference information, and then adjust it according to local policy and real-time monitoring.

Packet Stream Generation N/A

Traffic Filtering (Observation) Details N/A

Sampling Distribution Sampling method: Event-driven and periodic sampling. The service site monitors internal instances continuously. GAS updates are reported when they become operationally significant (e.g., crossing a configured threshold, health status changes). A periodic heartbeat or soft-state synchronization MAY be used to refresh the C-PS view.

Runtime Parameters and Data Format CS-ID: CATS Service Identifier (format as defined in ) CSCI-ID: CATS Service Contact Instance Identifier (format: ipv4-address-no-zone or ipv6-address-no-zone, complying with ) max_capacity: Maximum concurrent request capacity per instance (Units: count; Format: uint32) active_sessions: Current active session count (Units: count; Format: uint32) health_status: Instance health status (Format: boolean or enumerated value) policy_factor: Local policy safety margin (Units: percentage; Format: decimal; Default: 1.0)

Roles C-SMA (via Metric Aggregator): Collects instance-level metrics, calculates GAS according to local policy, and reports significant changes to the C-PS. C-PS: Receives GAS values, maintains the Computing Service Table, and uses GAS for admission control and traffic steering decisions.

Output

Type Singleton value

Reference Definition Output format: A single non-negative integer representing the number of available concurrent client slots. Score semantics:

• GAS > 0: The service site can accept new requests.
• GAS = 0: The service site is at capacity; no new requests should be steered to this CSCI-ID.

Metric Units Count (number of concurrent client slots)

Calibration Calibration method: The service site SHOULD validate GAS accuracy through controlled load testing. The deviation between reported GAS and actual observed capacity SHOULD be minimized (e.g., within 5% under representative workload profiles).

Administrative Items

Status Current

Requester IETF CATS Working Group

Revision 1.0

Revision Date 2026-08-07

Comments and Remarks This is a mandatory Computing Service Metric. GAS is the core metric that enables direct admission control in CATS traffic steering.

Computing Time

Summary

ID (Identifier) IANA has allocated the Identifier TBD2 for this Named Metric Entry. See for the mapping to Names.

Name Svc_Passive_CATS-Service_ComputingTime_RFCXXXXsecY_Milliseconds_Singleton

URI To-be-assigned.

Description Computing Time represents the time required for a service site to perform one service request. It is a service-oriented metric that abstracts the processing delay of the deployed service instance. The service site can initialize this metric based on service reference information (e.g., Reference Computing Time from a public service platform) and then measure or estimate it according to the runtime behavior of the deployed service instance. The service site dynamically adjusts this metric based on real-time load and local policy. Computing Time is used by the C-PS to calculate total service time (computing time plus network delay) for traffic steering decisions.

Change Controller IETF

Version 1.0

Metric Definition

Reference Definition Core referenced sections: Section 4.2.2 (Computing Time)

Fixed Parameters

• Metric type: "comp_time"
• Level: Service-oriented (L0/TBD)
• Data type: non-negative integer or floating-point
• Metric units: Milliseconds (ms)
• Initial value: Derived from service reference information or benchmark measurement

Method of Measurement

Reference Methods Computing Time is measured or estimated by the service site based on the runtime behavior of the deployed service instance. The specific measurement method is a local matter, but the following approaches are common:

• Weighted average of instance response times, weighted by instance load.
• Median or percentile (e.g., p95) of instance response times to account for outliers.
• Dynamically adjusted estimate based on current load and historical trends.

The service site MAY also report min/max computing time and the associated input token counts for reference (e.g., in AI inference services). The service site dynamically adjusts this metric based on real-time load and local policy.

Packet Stream Generation N/A

Traffic Filtering (Observation) Details N/A

Sampling Distribution Sampling method: Continuous sampling with event-driven updates. The service site monitors response times continuously. Updates are reported when Computing Time deviates beyond a configured percentage band or when significant load changes occur.

Runtime Parameters and Data Format CS-ID: CATS Service Identifier (format as defined in ) CSCI-ID: CATS Service Contact Instance Identifier (format: ipv4-address-no-zone or ipv6-address-no-zone, complying with ) response_time_samples: Array of observed response times (Units: ms; Format: array of uint32 or float) load_factor: Current load factor affecting response time (Units: percentage; Format: decimal) input_size: Size of input data for reference (e.g., token count for LLM services) (Units: count; Format: uint32; Optional)

Roles Service Contact Instance / C-SMA: Measures or estimates Computing Time based on runtime behavior and reports significant changes to the C-PS. C-PS: Receives Computing Time values, combines them with network delay from the Network Service Table to calculate total service time for traffic steering.

Output

Type Singleton value (with optional min/max range)

Reference Definition Output format: A single non-negative value representing the expected computing time in milliseconds. Implementations MAY also provide minimum and maximum observed values. Score semantics:

• Lower values indicate faster service processing.
• Higher values indicate slower service processing.
• The C-PS uses Computing Time together with network delay to select the optimal CSCI-ID.

Metric Units Milliseconds (ms)

Calibration Calibration method: The service site SHOULD benchmark Computing Time using representative workload profiles. The reported value SHOULD reflect the expected response time under current load conditions with a deviation target of less than 10% from observed values.

Administrative Items

Status Current

Requester IETF CATS Working Group

Revision 1.0

Revision Date 2026-08-07

Comments and Remarks This is a mandatory Computing Service Metric. Computing Time is essential for calculating total service time in CATS traffic steering decisions.

Cost

Summary

ID (Identifier) IANA has allocated the Identifier TBD3 for this Named Metric Entry. See for the mapping to Names.

Name Svc_Passive_CATS-Service_Cost_RFCXXXXsecY_Unitless_Singleton

URI To-be-assigned.

Description Cost represents the self-defined price set by the service site to apply administrative or economic billing policies. It is an optional extension metric that enables cost-aware traffic steering. The cost value is determined entirely by the service provider's local policy and may reflect factors such as resource scarcity, energy prices, service level agreements, or competitive pricing.

Change Controller IETF

Version 1.0

Metric Definition

Reference Definition Core referenced sections: Section 4.3.1 (Cost)

Fixed Parameters

• Metric type: "cost"
• Level: Service-oriented (L0/TBD)
• Data type: non-negative integer or floating-point
• Metric units: Unitless (provider-defined currency or pricing unit)
• Initial value: Defined by service provider policy

Method of Measurement

Reference Methods Cost is self-defined by the service site based on local administrative or economic billing policies. It is not derived from raw hardware metrics but is set according to provider-specific factors such as:

• Resource scarcity (e.g., edge GPUs may have higher cost than central cloud resources).
• Energy prices and operational expenses.
• Service Level Agreement (SLA) tiers.
• Competitive market pricing.

The service site MAY adjust the cost value dynamically based on demand, time of day, or other business policies.

Packet Stream Generation N/A

Traffic Filtering (Observation) Details N/A

Sampling Distribution Sampling method: Policy-driven updates. Cost changes are reported when the service site updates its pricing policy. A periodic heartbeat MAY be used to ensure consistency.

Runtime Parameters and Data Format CS-ID: CATS Service Identifier (format as defined in ) CSCI-ID: CATS Service Contact Instance Identifier (format: ipv4-address-no-zone or ipv6-address-no-zone, complying with ) cost_value: The cost value (Format: uint32 or decimal; Unit: provider-defined) currency_unit: Optional indicator of the pricing unit (Format: string; Optional)

Roles Service Site / C-SMA: Defines and reports the cost value according to local policy. C-PS: Receives cost values and MAY use them as a tie-breaker or primary criterion in traffic steering policies (e.g., selecting the lowest-cost eligible instance).

Output

Type Singleton value

Reference Definition Output format: A single non-negative value representing the cost. Score semantics:

• Lower values indicate lower cost.
• Higher values indicate higher cost.
• The C-PS MAY use cost to rank candidates after filtering by other criteria (e.g., GAS > 0, Computing Time within threshold).

Metric Units Unitless (provider-defined pricing unit)

Calibration N/A. Cost is a policy-defined nominal value, not a measured performance metric.

Administrative Items

Status Current

Requester IETF CATS Working Group

Revision 1.0

Revision Date 2026-08-07

Comments and Remarks This is an optional extension metric. Cost enables economic-aware traffic steering but is not required for basic CATS operation.

Reputation

Summary

ID (Identifier) IANA has allocated the Identifier TBD4 for this Named Metric Entry. See for the mapping to Names.

Name Svc_Passive_CATS-Service_Reputation_RFCXXXXsecY_Score_Singleton

URI To-be-assigned.

Description Reputation represents a dynamic quality score based on user feedback and observed service performance. It reflects the historical quality of service provided by a service site. Upon service completion, if a user experiences long delays or inaccurate results, feedback is returned to the C-PS along with the resource release message. The C-PS or service site aggregates this feedback into a reputation score.

Change Controller IETF

Version 1.0

Metric Definition

Reference Definition Core referenced sections: Section 4.3.2 (Reputation)

Fixed Parameters

• Metric type: "reputation"
• Level: Service-oriented (L0/TBD)
• Data type: non-negative integer
• Metric units: Score (typically 0-10 or 0-100 scale)
• Initial value: Default or bootstrap value set by provider

Method of Measurement

Reference Methods Reputation is derived from user feedback and observed performance metrics. The specific aggregation algorithm is implementation-specific, but common approaches include:

• Moving average of user satisfaction ratings.
• Penalty-based scoring for timeout or error events.
• Combination of objective metrics (success rate, delay compliance) and subjective user ratings.

Feedback is typically collected upon session completion and aggregated over a configurable time window.

Packet Stream Generation N/A

Traffic Filtering (Observation) Details N/A

Sampling Distribution Sampling method: Event-driven sampling based on user feedback and session completion events. The reputation score is updated periodically (e.g., every hour or day) based on accumulated feedback.

Runtime Parameters and Data Format CS-ID: CATS Service Identifier (format as defined in ) CSCI-ID: CATS Service Contact Instance Identifier (format: ipv4-address-no-zone or ipv6-address-no-zone, complying with ) feedback_score: Individual user feedback score (Format: integer; Range: 0-10 or 0-100) success_indicator: Whether the session completed successfully (Format: boolean) delay_compliance: Whether the delay SLA was met (Format: boolean) aggregation_window: Time window for aggregating feedback (Units: seconds; Format: uint32; Default: 3600)

Roles C-PS: Collects user feedback and session completion data, calculates reputation scores, and maintains reputation state. Service Site: MAY provide objective performance data (success rates, delay statistics) to support reputation calculation.

Output

Type Singleton value

Reference Definition Output format: A single non-negative integer representing the reputation score. Score semantics (example with 0-10 scale):

• 0-3: Poor reputation, avoid if alternatives exist.
• 4-7: Average reputation, acceptable for steering.
• 8-10: Excellent reputation, preferred for steering.

Metric Units Score (unitless, provider-defined scale)

Calibration Calibration method: The reputation calculation algorithm SHOULD be validated to ensure it accurately reflects service quality. The C-PS SHOULD implement anti-gaming measures to prevent manipulation of reputation scores.

Administrative Items

Status Current

Requester IETF CATS Working Group

Revision 1.0

Revision Date 2026-08-07

Comments and Remarks This is an optional extension metric. Reputation enables quality-aware traffic steering based on historical performance.

Security Label

Summary

ID (Identifier) IANA has allocated the Identifier TBD5 for this Named Metric Entry. See for the mapping to Names.

Name Svc_Passive_CATS-Service_SecurityLabel_RFCXXXXsecY_Score_Singleton

URI To-be-assigned.

Description Security Label reflects the security status of a service site. A higher score indicates a more secure site. It enables security-aware traffic steering, allowing the C-PS to prefer service sites with higher security posture. The security label is evaluated by the service site based on local security policies, compliance status, threat intelligence, and security monitoring.

Change Controller IETF

Version 1.0

Metric Definition

Reference Definition Core referenced sections: Section 4.3.3 (Security Label)

Fixed Parameters

• Metric type: "security_label"
• Level: Service-oriented (L0/TBD)
• Data type: non-negative integer
• Metric units: Score (0-10 scale)
• Score range: 0-10 (0 indicates the poorest security; 10 indicates optimal security)

Method of Measurement

Reference Methods Security Label is estimated by the service site based on local security assessment. The specific evaluation criteria are a local matter, but may include:

• Compliance with security standards (e.g., ISO 27001, SOC 2).
• Presence of security controls (firewalls, intrusion detection, encryption).
• Threat intelligence and recent security incidents.
• Vulnerability scan results and patch levels.
• Physical security of the service site.

Packet Stream Generation N/A

Traffic Filtering (Observation) Details N/A

Sampling Distribution Sampling method: Periodic reassessment. The service site SHOULD re-evaluate the Security Label periodically (e.g., daily or upon significant security events) and report changes to the C-PS.

Runtime Parameters and Data Format CS-ID: CATS Service Identifier (format as defined in ) CSCI-ID: CATS Service Contact Instance Identifier (format: ipv4-address-no-zone or ipv6-address-no-zone, complying with ) security_score: The security label score (Format: uint8; Range: 0-10) assessment_date: Timestamp of the last security assessment (Format: RFC 3339 timestamp) compliance_flags: Optional bitmask indicating compliance with specific standards (Format: bit field; Optional)

Roles Service Site / C-SMA: Evaluates and reports the Security Label based on local security assessment. C-PS: Receives Security Label values and MAY use them to filter or rank service sites according to security policies (e.g., minimum security threshold).

Output

Type Singleton value

Reference Definition Output format: A single integer in the range 0-10 representing the security label. Score semantics:

• 0-3: Low security, not recommended for sensitive traffic.
• 4-7: Medium security, acceptable for general traffic.
• 8-10: High security, preferred for sensitive or regulated traffic.

Metric Units Score (unitless, 0-10 scale)

Calibration Calibration method: The service site SHOULD establish a consistent security assessment methodology. The mapping from security controls to the 0-10 score SHOULD be documented and reviewed periodically.

Administrative Items

Status Current

Requester IETF CATS Working Group

Revision 1.0

Revision Date 2026-08-07

Comments and Remarks This is an optional extension metric. Security Label enables security-aware traffic steering for sensitive workloads.

Capability (L1/L2 Compatibility)

Summary

ID (Identifier) IANA has allocated the Identifier TBD6 for this Named Metric Entry. See for the mapping to Names.

Name Svc_Passive_CATS-Service_Capability_RFCXXXXsecY_Score_Singleton

URI To-be-assigned.

Description Capability represents the overall computing and storage capability allocated by the service site. It maintains compatibility with the Level 1 and Level 2 normalized metrics defined in . When a normalized L1 or L2 overall capability score is available at the service site, this metric carries that value. It allows C-PS implementations that prefer normalized scores to interoperate with service sites that also provide Computing Service Metrics.

Change Controller IETF

Version 1.0

Metric Definition

Reference Definition Core referenced sections: Section 4.3.4 (Capability) Core referenced sections: Section 3.3 (Level 1 Metric Definition), Section 3.4 (Level 2 Metric Definition)

Fixed Parameters

• Metric type: "site_cap"
• Level: L1/L2 (as defined in )
• Data type: non-negative integer
• Metric units: Score (unitless, typically 0-10 scale)
• Normalization score range: 0-10 (0 indicates the poorest capability, 10 indicates the optimal capability)

Method of Measurement

Reference Methods Capability is derived from the Level 1 or Level 2 normalized metrics defined in . The service site calculates the normalized score using the aggregation and normalization functions specified in that document:

• Level 1 Capability: Aggregated and normalized score within a specific category (computing, communication, service, or composed).
• Level 2 Capability: A single normalized score aggregating all relevant Level 0 and/or Level 1 metrics.

The specific aggregation and normalization functions are implementation-specific, as described in Section 4.2.

Packet Stream Generation N/A

Traffic Filtering (Observation) Details N/A

Sampling Distribution Sampling method: Continuous sampling (e.g., collect underlying metrics every 10 seconds) with periodic reporting.

Runtime Parameters and Data Format CS-ID: CATS Service Identifier (format as defined in ) CSCI-ID: CATS Service Contact Instance Identifier (format: ipv4-address-no-zone or ipv6-address-no-zone, complying with ) capability_level: Indicates whether this is L1 or L2 (Format: enumerated value; Values: "L1", "L2") capability_category: For L1, indicates the category (Format: enumerated value; Values: "computing", "communication", "service", "composed"; N/A for L2) normalized_score: The normalized capability score (Format: uint8; Range: 0-10)

Roles C-SMA: Collects Level 0 raw metrics, calculates Level 1 or Level 2 normalized scores according to service/provider-specific strategies, and reports the Capability metric. C-PS: Receives Capability values and MAY use them as an alternative or complement to other Computing Service Metrics for traffic steering.

Output

Type Singleton value

Reference Definition Output format: A single integer in the range 0-10 representing the normalized capability score. Score semantics:

• 0-3: Low capability, not recommended for steering.
• 4-7: Medium capability, optional for steering.
• 8-10: High capability, priority for steering.

These semantics align with the Level 1 and Level 2 metric definitions in .

Metric Units Unitless (0-10 scale)

Calibration Calibration method: Conduct benchmark calibration based on representative workloads to align the mapping from Level 0 metrics to the normalized score, such that score deviation across measurement agents within the same administrative domain is minimized (e.g., less than 0.1 over repeated test rounds).

Administrative Items

Status Current

Requester IETF CATS Working Group

Revision 1.0

Revision Date 2026-08-07

Comments and Remarks This is an optional extension metric. Capability provides backward compatibility with the L1/L2 normalized metric framework defined in .

IANA Considerations This document requests IANA to create a new registry titled "CATS Computing Service Metrics" under the existing "Computing-Aware Traffic Steering (CATS)" heading. The initial entries for this registry are defined in Section 4 as follows: Initial Registry Entries

Identifier	Name
TBD1	Svc_Passive_CATS-Service_GAS_RFCXXXXsecY_Count_Singleton
TBD2	Svc_Passive_CATS-Service_ComputingTime_RFCXXXXsecY_Milliseconds_Singleton
TBD3	Svc_Passive_CATS-Service_Cost_RFCXXXXsecY_Unitless_Singleton
TBD4	Svc_Passive_CATS-Service_Reputation_RFCXXXXsecY_Score_Singleton
TBD5	Svc_Passive_CATS-Service_SecurityLabel_RFCXXXXsecY_Score_Singleton
TBD6	Svc_Passive_CATS-Service_Capability_RFCXXXXsecY_Score_Singleton

For each entry, IANA is requested to assign a unique Identifier from the registry's assignment pool. Each registry entry contains the following fields:

• Identifier: A unique integer assigned by IANA.
• Name: The formal metric name following the naming convention defined in Section 3.
• URI: A stable URI reference for the metric entry.
• Description: A brief description of the metric.
• Change Controller: The entity responsible for the metric definition (IETF for entries defined in this document).
• Version: The version of the metric definition.

The registration policy for this registry is "IETF Review" , meaning new entries require publication of an RFC or an IESG-approved document.

Security Considerations Computing Service Metrics, like all CATS metrics, are important inputs to traffic steering selection logic. Incorrect or manipulated metrics can directly affect forwarding behavior, potentially leading to service disruption, denial-of-service, or policy violation . Specific considerations for Computing Service Metrics include:

• GAS manipulation: A malicious service site could report artificially high GAS values to attract more traffic than it can handle, leading to overload and service degradation. The C-PS SHOULD implement sanity checks and cross-validation with other metrics (e.g., Computing Time, health status).
• Computing Time manipulation: A service site could under-report Computing Time to appear more attractive. The C-PS SHOULD validate reported values against observed response times and historical data.
• Cost manipulation: While cost is self-defined, the C-PS SHOULD ensure that cost-based steering policies cannot be exploited to circumvent other constraints (e.g., GAS > 0).
• Reputation gaming: Malicious users could attempt to manipulate reputation scores. The C-PS SHOULD implement anti-gaming measures such as rate limiting, identity verification, and outlier detection.
• Security Label trust: The Security Label is self-reported by the service site. The C-PS SHOULD verify security claims through independent audits or trusted third-party attestations where possible.

General security requirements for CATS metrics, including authenticity, integrity, freshness, and confidentiality, are defined in Section 7.

Normative References Harvard University IBM Informative References