Manageability Considerations for SCONE

1.1. SCONE Protocol Overview and Network Element Function

Deploying SCONE in a communication network involves the application endpoints and any SCONE-capable network elements along the path of a flow of QUIC UDP datagrams. SCONE is used on a QUIC flow only when its application endpoints support it. SCONE packets are QUIC long header packets carrying a SCONE-specific version number, coalesced into the same UDP datagram as the QUIC packets they accompany. This ensures that network elements that forward QUIC packets also forward the SCONE packets. Any network element can implement the SCONE network element function that sets the throughput advice.¶

To participate in SCONE, a network element is assumed to have the functional capability to identify and track SCONE-compliant QUIC flows, recognize and process SCONE packets within those flows, and map network policies into throughput advice to be inserted into the SCONE packets (see also Section 3.12).¶

By providing a standardized mechanism, SCONE allows network operators to provide throughput advice information to QUIC endpoints without custom APIs or per-network integrations. Applications can self-adapt to the throughput advice rather than relying on network rate limiters such as policers or shapers, and the network can update the throughput advice for an active flow, including to support tiered subscriber data plans (see Section 3.2 of [SCONE]).¶

When on-path network elements are present between the server and the client application end-points, their specific configuration and role will influence the advice they generate. Different network architectures handle flow visibility and policy enforcement at different points. In mobile networks, for example, the User Plane Function (UPF) in 5G [_5G-Arch] and the Packet Data Network Gateway (P-GW) in 4G network [_4G-Arch] can generate throughput advice to guide ABR applications on a per-flow basis. In contrast, other environments, such as wireline broadband or Wi-Fi, may apply policies at centralized aggregation points or gateways such as the Broadband Network Gateway serving multiple devices.¶

3.1. Flow Awareness and Per-Flow Signaling

As defined in the core SCONE protocol specification [SCONE], 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 conformance evaluation functions detailed later in this document (see Section 3.10), 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.¶

3.2. 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.¶

3.3. Considerations of Processing Complexity

As specified in Section 6.1 of [SCONE], 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 Section 7.1 of [SCONE], detection and modification of a SCONE packet to update the rate signal field is also a lightweight operation for a network element.¶

3.4. 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) (Section 5.4 of [SCONE]).¶

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.¶

3.5. 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 (Section 8.1 of [SCONE]). 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 (Section 7.1.2 of [SCONE], 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.¶

3.6. 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 Section 7.1.1 of [SCONE]). How soon the application sees the change depends on when the endpoint next sends a SCONE packet, since the network element cannot originate one.¶

3.7. 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 Section 7.1 of [SCONE]). This lets operators deploy and manage SCONE network elements independently, without building integration between them.¶

3.8. 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 Section 6.3 of [SCONE], 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 Section 6.1 of [SCONE]. 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 (Section 5.4 of [SCONE]) and the application operates without SCONE-advised limits.¶

3.9. 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 Section 8.2 of [SCONE]). This distinction does not change how a network element's own conformance measurement function responds (Section 3.10), 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 Section 7.2 of [SCONE]. 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.¶

3.10. Conformance Measurement

Networks that choose to provide SCONE throughput advice can implement mechanisms to monitor QUIC flows and measure conformance to 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 evaluates conformance only against the throughput advice that it set itself, rather than enforcing 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 an even longer sliding window to account for the possibility of packet loss.¶

Section 7.2 of [SCONE] explains that the second monitoring period in this window compensates for SCONE packets not being delivered reliably. Section 7.2 of [SCONE] presents the two-period baseline as illustrative, not mandatory, but cautions that monitoring more strictly than that baseline risks misclassifying a compliant application as non-conformant, 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 (Section 5.2 of [SCONE]) 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 conformance measurement and/or diagnostic approach described in Section 3.9 to check that the flow requires intervention in order to maintain target rates per Section 7.2.2 of [SCONE]. If the conformance measurement function 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 compliance enforcement. These deployment options are further explained in the next section.¶

3.11. 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 conformance measurements.¶

Conformance-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 compliant flows but requires conformance measurements as described in Section 3.10.¶

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 conformance measurements but may realize less network savings and may risk unwanted application impairments.¶

3.12. 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.¶

3.13. Interworking with Other Congestion Management Mechanisms

As stated in Section 3.1 of [SCONE], 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) [RFC3168] as also used by Low Latency, Low Loss, and Scalable Throughput (L4S) [RFC9330]. 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.¶

6.1. Normative References

[SCONE]

Thomson, M., Huitema, C., Oku, K., Joras, M., and L. M. Ihlar, "Standard Communication with Network Elements (SCONE) Protocol", Work in Progress, Internet-Draft, draft-ietf-scone-protocol-09, 24 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-scone-protocol-09>.

6.2. Informative References

[RFC3168]

Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/rfc/rfc3168>.

[RFC9330]

Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G. White, "Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture", RFC 9330, DOI 10.17487/RFC9330, January 2023, <https://www.rfc-editor.org/rfc/rfc9330>.

[_4G-Arch]

3GPP, "System Architecture for the Evolved Packet Core (EPC)", 1 June 2020, <https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=24300>.

[_5G-Arch]

3GPP, "System Architecture for the 5G System (5GS)", 7 January 2025, <https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144>.