Standard Communication with Network Elements S. Mishra Internet-Draft Verizon Intended status: Informational Z. Sarker Expires: 22 December 2026 Nokia A. Tomar Meta K. Abbas Verizon 20 June 2026 Applicability & Manageability Considerations for SCONE draft-ietf-scone-applicability-manageability-02 Abstract This document describes the Applicability and Manageability considerations for providing throughput guidance to application endpoints. This guidance is specifically addressed within the context of telecommunications service provider networks utilizing the Standard Communication with Network Elements (SCONE) protocol. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Standard Communication with Network Elements Working Group mailing list (scone@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/scone. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-scone/appman. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Mishra, et al. Expires 22 December 2026 [Page 1] Internet-Draft SCONE Applicability & Manageability June 2026 This Internet-Draft will expire on 22 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 3. Applicability, Manageability and Operational Considerations . . . . . . . . . . . . . . . . . . . . . 4 3.1. Flow Awareness and Per-Flow Signaling . . . . . . . . . . 4 3.2. Determining Throughput Constraints . . . . . . . . . . . 4 3.3. Considerations of Processing Complexity . . . . . . . . . 5 3.4. Reliability and Mitigating Packet Loss . . . . . . . . . 5 3.5. Frequency of Updates . . . . . . . . . . . . . . . . . . 6 3.6. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 6 3.7. Presence of SCONE Network Elements On the Data Path . . . 6 3.8. Change of Network Element During an Active Flow . . . . . 7 3.9. Monitoring and Logging . . . . . . . . . . . . . . . . . 7 3.10. Conformance Monitoring . . . . . . . . . . . . . . . . . 7 3.11. In-Band Signaling and Network Integration . . . . . . . . 8 3.12. Interworking with Other Congestion Management Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Mishra, et al. Expires 22 December 2026 [Page 2] Internet-Draft SCONE Applicability & Manageability June 2026 1. Introduction The SCONE protocol [I-D.ietf-scone-protocol] provides a signaling mechanism that enables on-path, SCONE-capable network elements to communicate "throughput advice", the advisory maximum allowable bit rate, to application endpoints via SCONE packets in the telecommunications service provider networks. Network elements capable of rate limiting can send notifications of the advisory maximum allowable bit rate in each direction of the observed traffic. This allows applications, particularly those using adaptive bit-rate (ABR) mechanisms,to proactively align their transmission rates with network policies. This document addresses the Applicability and Manageability considerations for deploying the SCONE protocol within service provider networks. It also addresses operational, configuration, and management aspects not covered in the core protocol specification. 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. 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. Encompassing deployment of network elements in a wide range of networks, this document is limited to discussing the core Applicability and Manageability considerations for the SCONE protocol to ensure its consistent and effective use across varied network paths. 2. Terms and Definitions This document uses terms and definitions described in [I-D.ietf-scone-protocol]. Mishra, et al. Expires 22 December 2026 [Page 3] Internet-Draft SCONE Applicability & Manageability June 2026 3. 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. 3.1. Flow Awareness and Per-Flow Signaling As defined in the core SCONE protocol specification [I-D.ietf-scone-protocol], 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. 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: Mishra, et al. Expires 22 December 2026 [Page 4] Internet-Draft SCONE Applicability & Manageability June 2026 * 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. 3.3. Considerations of Processing Complexity As specified in Section 6.1 of [I-D.ietf-scone-protocol], 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. 3.4. 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 [I-D.ietf-scone-protocol] 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 Mishra, et al. Expires 22 December 2026 [Page 5] Internet-Draft SCONE Applicability & Manageability June 2026 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 Section 3.5 and Section 3.3 for further guidance. 3.5. 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. 3.6. 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 [I-D.ietf-scone-protocol]). 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 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 [I-D.ietf-scone-protocol]). This lets operators deploy and manage SCONE network elements independently, without building integration between them. Mishra, et al. Expires 22 December 2026 [Page 6] Internet-Draft SCONE Applicability & Manageability June 2026 3.8. 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 [I-D.ietf-scone-protocol], 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 [I-D.ietf-scone-protocol]) 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. 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 3.10. 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. Mishra, et al. Expires 22 December 2026 [Page 7] Internet-Draft SCONE Applicability & Manageability June 2026 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. 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. 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 [I-D.ietf-scone-protocol]). Mishra, et al. Expires 22 December 2026 [Page 8] Internet-Draft SCONE Applicability & Manageability June 2026 3.12. 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) [RFC3168], and Low Latency, Low Loss, and Scalable Throughput (L4S) [RFC9330]. 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. Mishra, et al. Expires 22 December 2026 [Page 9] Internet-Draft SCONE Applicability & Manageability June 2026 4. Security Considerations This document does not add any additional security considerations. The core security and privacy considerations for the SCONE protocol are comprehensively defined in Sections 9 and 10 of [I-D.ietf-scone-protocol]. 5. IANA Considerations This document has no IANA actions. 6. References 6.1. Normative References [I-D.ietf-scone-protocol] Thomson, M., Huitema, C., Oku, K., Joras, M., and M. Ihlar, "Standard Communication with Network Elements (SCONE) Protocol", Internet-Draft, draft-ietf-scone- protocol, Work in Progress , July 2025, . 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, . [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, . [_4G-Arch] 3GPP, "System Architecture for the Evolved Packet Core (EPC)", 1 June 2020, . [_5G-Arch] 3GPP, "System Architecture for the 5G System (5GS)", 7 January 2025, . Mishra, et al. Expires 22 December 2026 [Page 10] Internet-Draft SCONE Applicability & Manageability June 2026 Acknowledgments The authors thank Wesley Eddy, Renjie Tang, Kevin Smith, Tina Tsou, Tianji Jiang, Lucas Pardue, and Martin Thomson for their helpful comments and contributions to this document. The authors are also grateful to Mirja Kühlewind, Gorry Fairhurst, Marcus Ihlar, Qin Wu, Christian Huitema, and Brian Trammell for their detailed reviews and contributions, which substantially improved this document. The authors also thank members of the SCONE Working Group for their review and support throughout the development of this document. Authors' Addresses Sanjay Mishra Verizon Email: sanjay.mishra@verizon.com Zaheduzzaman Sarker Nokia Email: zaheduzzaman.sarker@nokia.com Anoop Tomar Meta Email: anooptomar@meta.com Khurram Abbas Verizon Email: khurram.abbas@verizonwireless.com Mishra, et al. Expires 22 December 2026 [Page 11]