Manageability Considerations for SCONE

Manageability and Operational Considerations Encompassing deployment of network elements in a wide range of networks, this document is limited to discussing the core manageability and operational considerations for the SCONE protocol to support its effective use across these varied network types.

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 may require establishing and maintaining per-flow context. Specifically, to execute the monitoring, logging, and flow measurement functions detailed later in this document (see ), the network element has to 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 potentially necessary policy enforcement.

Deriving Throughput Advice The specific algorithms used to calculate throughput advice are highly dependent on 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: The throughput advice may be based on the subscriber's data plan. However, that does not mean that the rate limit is static but could be updated e.g. when a subscriber reaches a data plan threshold or usage cap. Similarly different limits may apply to different access technologies and a network or mobility event that implies a change of access technology then leads to an updated throughput advice signal.
Capacity and Load Management: The throughput advice signal may be updated as network conditions change, e.g. during periods of unusually high usage, sustained overuse, or temporary equipment faults. In this case, the network element may temporarily lower its throughput advice to manage shared capacity and guide application usage. A mobility event that moves the flow to a different cell with a different load profile, even without a change in access technology, can similarly trigger an updated throughput advice signal based on operator policy.

Considerations of Processing Complexity As specified in , SCONE-aware endpoints add SCONE indication bytes as the last two bytes of the payload of each UDP datagram that starts a new flow, to support the identification of a SCONE-capable flow without any need for compute-intensive flow classification. Additionally, SCONE-capable endpoints, through rate self-adaptation, remove the need for complex rate-limiting functions in the network element. Support for SCONE indication and rate self-adaptation reduces complexity and CPU processing load in the network element. Similarly, as explained in , detection and modification of a SCONE packet to update the rate signal field is also a lightweight operation for a network element.

Managing Processing Load The act of updating a SCONE packet is inherently stateless, since a network element simply modifies a traversing packet based on its current policy, without needing to remember anything about the flow. Only if the network element decides to update at a lower rate or only a selected set of SCONE-enabled flows, it might need to hold a minimum amount of per-flow state to ensure that each active flow receives the rate signal at least once within a monitoring period. Where a network element already maintains per-flow state for other functions, such as rate limiting a selected set of flows, this additional state and processing effort is minimal. Alternatively, network elements that do not already maintain per-flow state, can manage load instead by simply limiting the overall SCONE update rate, as SCONE is designed such that not every datagram that carries a SCONE packet needs to be updated. Only if no rate signal is received within a monitoring period, the rate signal is considered expired (at least for the next monitoring period) (). If a network element maintains throughput advice for only a selected set of flows, at least every flow in that set receives updates persistently within each monitoring period. Updating all flows at partial intervals instead can cause endpoints to alternate between operating with SCONE throughput advice and operating without it. Which flows continue to receive updates and how that selection changes over time are operator policy decisions. Network element implementations can provide the configuration options through which operators define and adjust that policy.

Reliability of Throughput Advice Delivery The frequency at which SCONE packets arrive at a network element is set by the application endpoint, not the network, and varies by application type and traffic pattern (). A network element cannot expect a predictable or uniform signaling cadence from the traffic itself, and instead decides its own update interval within that flexibility. Applications are incentivized to keep the sending frequency low to avoid high overhead, but still need to manage a sending rate that enables adaptation to throughput advice changes in a reasonable time. Even a high frequency is expected to be on the order of multiple seconds, since most applications can only apply a change at discrete intervals, such as an ABR application's next video segment. Sending at a much higher frequency than that would only waste resources for both the network and the endpoints without additional benefit. 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). This baseline ensures advice reliably reaches the endpoint and does not expire across the monitoring period, since SCONE packets are not delivered reliably for a variety of reasons. Operators may choose to update more frequently than this baseline, at the cost of additional network element CPU load, in exchange for a lower chance that advice goes unheard during any single window. A network enforcing fixed, subscription-based policies can typically rely on this baseline, since the applicable policy for a flow does not usually change once established. In practice, the network element can only update advice when a SCONE packet is available to modify. When the interval has elapsed, the network element waits for the next SCONE packet, and that arrival is what sets the real interval between updates.

Sending Updates for Dynamic Target Throughput Changes Target throughput advice can change while a flow is active, for example when a subscriber reaches a data threshold or when the radio access technology changes or when the bandwidth allocated to the subscriber or the bearer changes while the flow is already established. When this happens, the network element updates the next SCONE packet it observes, rather than waiting for its update interval to elapse, to minimize the application's reaction time to the new limit (see ). 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 Multiple 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. A network element might receive a packet that already includes a rate signal set to a valid value (not unknown). The network element replaces the rate signal if it wishes to signal a lower value for throughput advice; otherwise, the original values are retained, preserving any lower advice already set by another element on the path. This way the endpoint applies the most restrictive advice along the path (see ). This lets operators deploy and manage SCONE network elements independently, without building integration between them.

Change of Network Element If the network path changes, for example during QUIC connection migration, the flow can be routed through a different SCONE network element. Because SCONE signaling is stateless, this transition requires no explicit teardown or state transfer between the old and new network elements. As defined in , the endpoint sends SCONE packets early on the new path, so the new network element can detect the flow and provide its own advice. Because this is not a new flow, the new network element does not observe the flow-start indication described in . It detects the flow directly from the SCONE packet itself. If no SCONE-capable element is present on the new path, the previous advice expires after a monitoring period () 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. Operators benefit from collecting and logging the following flow-level information:

Signaling Events: the timestamps of SCONE packet updates on a given flow (same UDP address tuple), along with the throughput advice values communicated.
Per-Flow Throughput: the observed throughput of SCONE-enabled flows over time, such as across successive monitoring periods.

A network element cannot directly detect whether a SCONE packet was successfully delivered to or acted on by the endpoint, since SCONE provides no feedback channel from the endpoint (see ). This distinction does not change how a network element's own flow monitoring function responds (), which applies uniformly regardless of cause or location. When a flow's observed throughput does not appear to reflect the throughput advice provided, comparing the timestamps of issued updates against the flow's subsequent throughput can help narrow this down, consistent with the monitoring guidance in . If updates continued but throughput did not change accordingly, the issue lies after the network element, indicating either that the updated packets were dropped before reaching the endpoint, or that the endpoint received them but did not act on the advice. If a flow that is still generating throughput stops producing new SCONE update timestamps, the issue lies before the network element, suggesting either a delivery failure on the path to it, or that the sender is no longer sending SCONE packets on that flow.

Monitoring Flows Against Throughput Advice Networks that choose to provide SCONE throughput advice can implement mechanisms to monitor QUIC flows and measure flows against the throughput advice, 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 throughput advice. 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 need to ensure a network element monitors flows only against the throughput advice that it set itself, rather than enforcing limits based on advice set by other downstream network elements. When monitoring flows, 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 an even longer sliding window to account for the possibility of packet loss. explains that the second monitoring period in this window compensates for SCONE packets not being delivered reliably. presents the two-period baseline as illustrative, not mandatory, but cautions that monitoring more strictly than that baseline risks incorrectly classifying an application as not following advice, while a longer window carries no such risk. Waiting the full two periods is therefore the safe and simpler choice after a signaling update. A network element that can actively restart the monitoring window and track closely how many SCONE packets it has updated since a change in advice may be able to shorten this window. If it has updated at least two SCONE packets with the new advice for reliability, it can restart the monitoring period for one more 67-second interval and reach a decision after that period, rather than waiting a full two periods from the original change. Operators that do not track updates this closely should simply wait for the full two periods, which remains the safe and simpler choice. Operators should only shorten the window when they can track updates this reliably, weighing the added tracking complexity and how a missed update is treated against the benefit of a faster measurement cycle. 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 flows that exceed the limits that are set in their policies. Before applying rate-limiting (throttling) mechanisms on SCONE-capable flows, operators can use flow monitoring and/or the diagnostic approach described in to check that the flow requires intervention in order to maintain target rates per . If flow monitoring detects that an application is not following the signaled throughput advice, the network can employ 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 rate-limiting mechanism fallback, prioritizing cooperative application optimization over strict enforcement. These deployment options are further explained in the next section.

Deployment Options SCONE provides explicit signaling of throughput advice. SCONE is an alternative to using in-network rate limiting for load management or enforcement of subscription policies, providing better quality of experience for application users. Note that the use of SCONE throughput advice signaling can also provide these benefits to networks that are not applying rate limiting. This leads to three different deployment options for operators:

SCONE Signaling-only mode:: Operators that do not enforce any rate limits might provide SCONE throughput advice to support the application with a choice of a stable rate below the capacity limit leading to a more smooth user experience. Operators can also use SCONE throughput advice to enforce different rates as per subscriber data plans. This operation mode does not require the deployment of rate limits or any flow monitoring.
Monitoring-based rate enforcement mode:: Operators that use rate limits might disable rate enforcement for SCONE flows and only enable it dynamically if a SCONE flow is detected to not apply the limit itself. This mode saves network processing and buffer resources for flows that follow the advice but requires flow monitoring as described in .
Unconditional rate enforcement mode:: While SCONE is designed independent of any enforcement mechanism and it is therefore possible to statically enforce rate limits even when SCONE is used, this deployment is not recommended as it can risk worse performance. Doing so will remove most of the positive effects that SCONE provides, both in terms of end-user QoE and for network simplifications. This is because, SCONE enables traffic characteristic aware application driven bit-rate regulation but on the other hand in-network rate limiters enforces the rate-limits arbitrarily and indiscriminately without being aware of traffic characteristics. Therefore if unconditional rate enforcement mode is used, the in-network enforced rate needs to be significantly higher than the SCONE throughput advice just to guard against worst case scenario. This mode does not require flow monitoring but may realize less network savings and may risk unwanted application impairments.

Network Integration of SCONE In-Band Signaling Because SCONE packets are always coalesced with ordinary QUIC packets, SCONE signaling operates entirely in-band. 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. As such, SCONE seamlessly integrates into existing network architectures without requiring new data paths, e.g. using tunnels, nor introducing any additional routing overhead. Similarly, operators are not required to deploy any additional out-of-band signaling interfaces.

Using SCONE in tunnels and for QUIC-based tunnels in MASQUE SCONE does not depend on MASQUE or any other tunneling mechanism but it can be used in tunneling scenarios if desired. When traffic is tunneled on the network path, such as when using MASQUE , SCONE can be carried on the inner traffic but can also be used on a QUIC-based tunnel itself. If the inner traffic is SCONE-capable, each tunnel endpoint can be a SCONE-capable network element. In this case, as the tunnel endpoints have visibility into the demultiplexed tunneled traffic, throughput advice can be applied to individual tunneled flows. Which tunneled flows receive throughput advice is a matter of local policy at the network element. If a MASQUE tunnel uses a SCONE-enabled QUIC connection, the SCONE-capable network element is on the path between the MASQUE client and the MASQUE proxy. In this case, only the QUIC connection of the tunnel is visible to the network element which might carry multiple end-to-end flows. End-to-end SCONE packets ought not to be exposed outside a tunnel unless the tunnel itself is intended to expose SCONE. This also holds when techniques such as QUIC-aware proxying are used, which currently apply only to QUIC short header packets. It is recommended that end-to-end SCONE packets be fully encapsulated within the tunnel. Where flows are tunneled, throughput advice applies to the flow to which it was attached only. If the tunnel endpoint is also the application endpoint, this might mean that a QUIC flow that is tunneled in QUIC might have multiple, independent pieces of throughput advice. If the MASQUE client is not also the endpoint of the end-to-end QUIC connection, the tunnel egress might consider the throughput advice of the outer tunnel when providing throughput advice on the inner SCONE-enabled flows. Using SCONE on a MASQUE QUIC tunnel connection can enable throughput advice also for tunneled non-QUIC traffic, however, this can only be applied if there is an interface or mechanism in the tunnel that provides the throughput advice to the application.

Interworking with Other Congestion Management Mechanisms As stated in , SCONE throughput advice is not a substitute for congestion control utilizing congestion signals such as packet loss based on transport acknowledgments, delay, or Explicit Congestion Notification (ECN) as also used by Low Latency, Low Loss, and Scalable Throughput (L4S) . Rather, they are complementary. Congestion control applies a throughput limit different from the signaled throughput advice. Congestion control manages the immediate dynamics of the bottleneck link, while SCONE informs the application of the maximum rate allowed by network policy. Congestion signals provide real-time information on transient congestion for a network path, typically operating on the time scale of a round-trip time (RTT), whereas SCONE throughput advice operates over a much longer period. When the throughput advice is below the congestion limit and the application adheres to it, congestion control remains application-limited and does not act. However, in cases of high load, congestion control would limit the throughput below the provided advice, as the throughput 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. Operators can use SCONE to communicate static or dynamically adapted advice based on available policy information, e.g. based on subscriber data, or load management policies. Operators set this advice independent of instantaneous link congestion and do not need to coordinate throughput advice policies with congestion control. It is then up to the applications, such as ABR video clients or bulk downloads, to utilize this advice according to their specific use cases. Network operators can deploy SCONE alongside L4S or standard ECN as two independent network functions. Throughput advice is carried within the QUIC payload, which does not interact with or modify ECN markings of the IP-layer ECN field. Real-time congestion feedback mechanisms remain outside the SCONE domain.