Applicability & Manageability Considerations for SCONE

Applicability, Manageability and Operational Considerations Deploying SCONE in an operator network involves the application endpoints and any SCONE-capable network elements along the path of a flow. SCONE is used on a flow only when its application endpoints support it. Network elements that forward QUIC packets also forward the SCONE packets carried among them, and specific network elements implement and configure the SCONE Network Element function that sets the throughput advice. This document as a whole covers the applicability, manageability, and operational considerations for deploying SCONE in such networks.

Flow Awareness and Per-Flow Signaling As defined in the core SCONE protocol specification , throughput advice is associated with the flow of QUIC UDP datagrams sharing the same address tuple (IP version, source and destination IP addresses, and UDP ports). Because throughput advice applies strictly to this specific flow, SCONE Network Elements need to unambiguously associate their policy limits with the correct QUIC flows. However, the act of applying SCONE throughput advice is inherently stateless. To provide advice, a network element simply identifies a traversing SCONE packet and updates its value based on the configured policy for that flow or network scope, without needing to maintain active per-flow state. While the signaling itself is stateless, managing the operational lifecycle of a SCONE deployment requires establishing and maintaining per-flow context. Specifically, to execute the monitoring, logging, and conformance evaluation functions detailed later in this document, the network element must track the flow's throughput over multiple monitoring periods. This per-flow context serves as the operational foundation for validating whether an application is adhering to the advised rate and for applying any necessary policy enforcement.

Determining Throughput Constraints The specific algorithms used to calculate throughput advice are highly dependent on an operator's network architecture. In practice, these constraints are often derived from a combination of network policies, real-time conditions where applicable, and any other business logic the operator applies. The inputs below are illustrative and will likely vary by operator, and they are not exhaustive. A SCONE-capable network element may derive its throughput advice from one or more of the following:

Subscriber Policies and Data Plans: Rate limits may apply when a subscriber reaches a data plan threshold or usage cap, and the network element bases its throughput advice on that subscriber policy.
Application-Specific Policies: Operators may set maximum bit-rates for certain types of traffic based on subscription tier or device type, for example video optimization for adaptive bitrate video, or traffic shaping for low-priority bulk transfers such as background software updates.
Dynamic Network Conditions: Constraints may be updated as network conditions change, for example when a flow moves to a different access network.
Capacity and Load Management: During periods of unusually high usage, sustained overuse, or temporary equipment faults, the network element may temporarily lower its throughput advice to manage shared capacity and guide application usage.

Considerations of Processing Complexity As specified in Section 6.1 of , SCONE-aware endpoints provide a specific indication on the first SCONE packet to support the identification of a SCONE-capable flow without any need for compute-intensive flow classification. Additionally, SCONE-capable endpoints, through bit-rate self-adaptation, remove the need for complex rate-limiting functions in the network element. Support for SCONE indication and bit-rate self-adaptation reduces complexity and CPU processing load in the network element.

Reliability and Mitigating Packet Loss Packet loss or non-delivery of SCONE advice directly reduces its effectiveness. Because the reliable delivery of throughput advice relies entirely on the periodic sending of SCONE packets by application endpoints, Section 7.1 ("Applying Throughput Advice Signals") of leaves the exact update frequency flexible. This flexibility allows operators to manage the tension between signaling reliability and network CPU load. A SCONE-enabled network element updates advice in SCONE packets at least twice per the 67-second monitoring period (approximately every 20 to 30 seconds), but operators may choose to process and update SCONE packets more frequently to better mitigate packet losses or to ensure timely notifications to the application. Therefore, the network element needs to make independent operational decisions on how frequently to update those traversing packets. A network enforcing dynamic policies might prioritize updating SCONE packets immediately upon a policy trigger to minimize the application's reaction time to the new limit. Conversely, a network enforcing fixed, subscription-based policies can safely scale back its update frequency to the 20 to 30-second baseline to conserve CPU resources. This baseline periodic update frequency ensures that the throughput advice reliably reaches the endpoint and does not inadvertently expire across the standard 67-second monitoring period due to normal packet loss. Operators balancing this reliability against network element overhead can refer to and for further guidance.

Frequency of Updates For network operators, understanding that SCONE signaling is fundamentally decided by the application endpoint is critical. Because a SCONE Network Element relies entirely on these endpoint-generated packets to communicate throughput advice, the frequency of traversing SCONE packets varies depending on the specific application type and its traffic characteristics. Consequently, network elements need to be prepared to apply updates to traversing packets at highly variable, application-driven intervals rather than expecting a predictable or uniform signaling cadence from the network side.

Dynamic Updates Target throughput advice can change dynamically while a flow is active, for example when a subscriber reaches a data threshold or a network policy changes. When this happens, the network element can update the next traversing SCONE packet with the new throughput advice (see Section 9.2 of ). How soon the application sees the change depends on when the endpoint next sends a SCONE packet, since the network element cannot originate one.

Presence of SCONE Network Elements On the Data Path When multiple SCONE-capable network elements are present on the same data path, they operate independently, with no synchronization or control-plane coordination required between them. Each network element only lowers the rate signal, preserving any lower advice already set by another element on the path, so the endpoint applies the most restrictive advice along the path (see Section 5.4 of ). This lets operators deploy and manage SCONE network elements independently, without building integration between them.

Change of Network Element During an Active Flow The on-path network element can change when an application changes its access network, for example during QUIC connection migration or a mobility event where the IP address is unchanged. Because SCONE signaling is stateless, this transition needs no explicit teardown or state transfer between the old and new network elements. The endpoint and network elements follow the migration steps defined in Section 6.3 of , where the endpoint sends SCONE packets early on the new path so a network element there can detect the flow and provide its own advice. If no SCONE-capable element is present on the new path, the previous advice expires after a monitoring period (Section 5.4 of ) and the application operates without SCONE-advised limits.

Monitoring and Logging SCONE signaling can be integrated into existing operational and management frameworks to enable monitoring, troubleshooting, and fault isolation. Metrics of interest include:

Rate of SCONE advisory messages issued per session
Correlation between SCONE advisories and user-plane throughput changes
Error conditions where SCONE signaling fails to reach the intended endpoints

Conformance Monitoring Networks that choose to provide SCONE throughput advice can implement mechanisms to monitor QUIC flows and measure conformance to the advised bit-rate, either per flow of packets on the same UDP address tuple, or in aggregate across multiple QUIC flows if they contribute to a shared policy limit (such as a device or network subscription level). This will allow operators to validate whether applications are following the advised bit-rate. While it is expected that operators will implement monitoring at the SCONE Network Element providing the advice, it could also be performed elsewhere in the network. However, network elements lack the capability to validate the legitimacy of SCONE packets coalesced with other QUIC packets. Therefore, operators must ensure a network element evaluates conformance only against the advised bit-rate that it set itself, and never enforces limits based on advice set by other downstream network elements. When evaluating compliance, network operators will need to account for the time required for SCONE packets to be updated, received by endpoints, and acted upon by the application. Operators can accommodate this by utilizing a sliding window approach. Operators should evaluate QUIC flows against the highest throughput limit advised over the preceding two monitoring periods (a span of 134 seconds). If a network element cannot update the throughput advice in every traversing SCONE packet, operators might configure a longer sliding window to account for the possibility of packet loss. To simplify the measurement function, reduce computational load, or offload this function to another node in the network, operators can select any value larger than the baseline 67-second window for their measurement and averaging period. Because some applications will not support SCONE, and others either will not or cannot follow the provided throughput advice, operators have flexibility in how they handle violations. If the monitoring function detects a violation where an application is not respecting the signaled throughput advice, the network can employ a throttling fallback. This involves falling back to traditional rate-limiting mechanisms, such as dropping or delaying packets, to ensure the QUIC flow does not exceed the throughput limits set by network policy. Alternatively, operators can deploy SCONE purely as an advisory signal without any throttling fallback, prioritizing cooperative application optimization over strict compliance enforcement.

In-Band Signaling and Network Integration Because SCONE packets are always coalesced with ordinary QUIC packets, SCONE signaling operates entirely in-band. It does not introduce any additional routing overhead or require the creation of out-of-band signaling interfaces. Instead, SCONE signaling inherently traverses the already established network path, such as the existing connection between a user device and a network gateway, associated with the QUIC flow for which the network element intends to send throughput advice. This ensures that SCONE seamlessly integrates into existing architectures without requiring new tunnels or data paths to be established. By providing a standardized mechanism, SCONE allows network operators and QUIC endpoints to exchange bit-rate information without custom APIs or per-network integrations. Applications can self-adapt to the advised bit-rate rather than relying on network rate limiters such as policers or shapers, and the network can update the advised bit-rate for an active flow, including to support tiered subscriber data plans (see Section 3.2 of ).

Interworking with Other Congestion Management Mechanisms SCONE throughput advice is not a substitute for congestion control mechanisms in transport protocols utilizing congestion feedback and signals such as acknowledgments, Explicit Congestion Notification (ECN) , and Low Latency, Low Loss, and Scalable Throughput (L4S) . Rather, they are complementary. Congestion signals provide real-time information on loss, delay, and transient congestion for a network path, typically operating on the time scale of a round-trip time (RTT). In contrast, SCONE throughput advice operates over a much longer period. Because the network element is generally unaware of the specific application traffic, it simply provides static or dynamically adapted advice based on available policy information. Operators can use SCONE to communicate these maximum allowable bit-rates driven by video optimization, subscriber data, or load management policies, independent of instantaneous link congestion. It is then up to the applications, such as adaptive bitrate video clients or bulk downloads, to utilize this advice according to their specific use cases. For network operators considering co-deployment, SCONE throughput advice is strictly independent of the IP-layer ECN field. Because SCONE advice is carried within the QUIC payload, updating the advice does not interact with or modify ECN markings. This independence ensures that operators can safely deploy SCONE alongside L4S or standard ECN. Real-time congestion feedback mechanisms remain fully operational and function completely outside the SCONE domain. Operators should expect that congestion signals might frequently indicate a throughput limit different from the signaled SCONE advice. In other words, in the best case, the throughput advice is below the congestion limit and when the application adheres to the advice, congestion control would be application-limited and not go into action. However, in cases of high load, congestion control would limit the throughput below the provided advice, as the SCONE advice is only an upper limit. As such, congestion control or a similar mechanism to react to congestion, such as a circuit breaker, is always needed in addition to SCONE. In environments where both are present, congestion control manages the immediate dynamics of the bottleneck link, while SCONE informs the application of the maximum rate allowed by network policy. Network operators will benefit from ensuring that throughput advice policies and congestion control configurations are consistent within scoped deployments, to avoid providing conflicting feedback to applications.