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

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. 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: The network element bases its throughput advice on the subscriber's data plan. This includes cases where rate limits apply once a subscriber's data volume usage reaches a threshold or usage cap.¶

• Application-Specific Policies: Operators may set maximum bitrates for certain types of traffic based on subscription tier or device type, for example video optimization for ABR 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.¶

3.3. Considerations of Processing Complexity

As specified in Section 6.1 of [SCONE], 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 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.¶

3.4. Network Element Overload Handling

Processing SCONE packets creates a per-flow update obligation for network elements. To avoid throughput advice expiring (Section 5.4 of [SCONE]), each active flow needs at least one rate signal update within each monitoring period. When the number of concurrent SCONE flows grows unusually large, as can occur during periods of elevated traffic or network stress, this update obligation can become a processing concern.¶

Network element vendors and operators have two broad options for managing this. One is to provision the network element with capacity that accommodates the expected range of concurrent flows, recognizing that what constitutes adequate capacity will vary by deployment. The other is to handle the condition gracefully when that capacity is reached. One approach for graceful handling is for the network element to stop updating SCONE packets for a subset of flows entirely, rather than attempting to serve all flows with intermittent or delayed updates. A flow that does not observe a SCONE update for a full monitoring period will have its throughput advice expire, causing the endpoint to operate without SCONE-advice. This outcome is more predictable than partial updates, which 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 7.1 of [SCONE], "Applying Throughput Advice Signals"). 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.¶

A SCONE-enabled network element updates advice in SCONE packets at least twice per the 67-second monitoring period (Section 5.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 9.3 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.¶

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

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

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

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