Standard Communication with Network Elements S. Mishra Internet-Draft Verizon Intended status: Informational Z. Sarker Expires: 11 August 2026 Nokia A. Tomar Meta K. Abbas Verizon 7 February 2026 Applicability & Manageability Considerations for SCONE draft-ietf-scone-applicability-manageability-01 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 11 August 2026 [Page 1] Internet-Draft SCONE Applicability & Manageability February 2026 This Internet-Draft will expire on 11 August 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 3. Applicability and Manageability Considerations . . . . . . . 3 3.1. Flow session awareness . . . . . . . . . . . . . . . . . 3 3.2. Per-Flow Signaling . . . . . . . . . . . . . . . . . . . 4 3.3. QoS awareness . . . . . . . . . . . . . . . . . . . . . . 4 3.4. SCONE Hint to the Network . . . . . . . . . . . . . . . . 4 3.5. Retransmission of Advised Bit-Rate . . . . . . . . . . . 4 3.6. Frequency of Updates . . . . . . . . . . . . . . . . . . 4 3.7. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 5 3.8. Monitoring and Logging . . . . . . . . . . . . . . . . . 5 3.9. Conformance Monitoring . . . . . . . . . . . . . . . . . 5 3.10. Standards Compliance . . . . . . . . . . . . . . . . . . 5 3.11. Interworking with Other Congestion Management Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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. Mishra, et al. Expires 11 August 2026 [Page 2] Internet-Draft SCONE Applicability & Manageability February 2026 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 application flows, recognize and process SCONE packets within those flows and map network policies into throughput advice to be inserted into the SCONE packets. While on-path network elements may exist at various points 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]. 3. Applicability and Manageability Considerations 3.1. Flow session awareness SCONE signaling operates only over established sessions. SCONE Network Elements ought to be able to unambiguously associate throughput advice with application flows. Each session is bound to an IP address and port, ensuring SCONE packets are routed precisely without affecting unrelated traffic. Mishra, et al. Expires 11 August 2026 [Page 3] Internet-Draft SCONE Applicability & Manageability February 2026 3.2. Per-Flow Signaling Throughput advice is applied on a UDP 4-tuple basis. SCONE Network Elements ought to maintain flow-specific context to ensure signaling correctness. This enables applications to receive targeted throughput advice while preventing unintended impact on unrelated flows. 3.3. QoS awareness Quality of Service (QoS) may be enforced by networks through a variety of mechanisms. In certain deployments, network operators may choose to apply distinct QoS policies to SCONE-enabled flows. The SCONE Network Element responsible for inserting SCONE advice is not required to interpret or enforce QoS policies; its role is limited to the signaling of the advisory throughput information. It is expected that network operators shall be able to identify SCONE-enabled flows and, where appropriate, provide throughput advice in accordance to their policy objectives. 3.4. SCONE Hint to the Network SCONE-aware applications ought to provide hints to the SCONE Network Elements, enabling it to generate appropriate throughput advice for a given UDP 4-tuple. Such hints prevent unnecessary default rate- limiting, allow the network to signal the maximum allowable bit rate, and reduce CPU overhead by eliminating additional classification steps. 3.5. Retransmission of Advised Bit-Rate Packet loss or non-delivery of SCONE advice reduces its effectiveness. Both SCONE Network Elements and application endpoints should support retransmission or periodic re-sending of SCONE packets to ensure reliable delivery. Conformance depends on the behavior of both network and application endpoint. 3.6. Frequency of Updates The rate at which SCONE updates are issued depends on flow characteristics and available computational resources. Excessively frequent updates may increase CPU load, while infrequent updates may reduce advisory effectiveness. Network Operators can define adjustable update intervals based on application requirements, network capacity, and operational constraints. Mishra, et al. Expires 11 August 2026 [Page 4] Internet-Draft SCONE Applicability & Manageability February 2026 3.7. Dynamic Updates Dynamic rate limits updates can be enforced by the network during active application sessions due to: * Changes in access network type (requiring updated throughput advice) * Changes in Subscriber policy (e.g., exceeding usage thresholds) In such cases, the SCONE Network Elements need to be able to initiate SCONE packets to provide updated advice, or applications should generate SCONE packets frequently enough to trigger network responses. 3.8. 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.9. Conformance Monitoring Networks providing SCONE throughput advice ought to implement mechanisms to measure compliance, either per application flow or in aggregate. This allows operators to validate advisory effectiveness and adjust policies. Due to flow awareness, such mechanisms are typically implemented in a SCONE Network Element but may also be implemented elsewhere in the network. 3.10. Standards Compliance SCONE signaling is expected to traverse the existing data path associated with the UDP 4-tuple flow for which the Network Element intends to send the advisory bit-rate. Mishra, et al. Expires 11 August 2026 [Page 5] Internet-Draft SCONE Applicability & Manageability February 2026 3.11. Interworking with Other Congestion Management Mechanisms SCONE is distinct from transport-level congestion control mechanisms, such as Explicit Congestion Notification (ECN) or Low Latency, Low Loss, and Scalable Throughput (L4S). While congestion control operates on short timescales to manage transient congestion caused by varying link conditions or instantaneous load, SCONE provides throughput advice based on relatively stable network policies or capacity management goals. ECN/L4S based congestion control works at transport level and SCONE works at application level. SCONE does not replace the need for endpoints to perform congestion control or network to provide explicit or implicit congestion signals; rather, it complements these mechanisms by providing a variable range for application-level rate adaptation. In environments where both are present, SCONE and congestion control mechanisms co-exist: congestion control manages the immediate dynamics of the bottleneck link, while SCONE informs the application of the maximum sustained rate allowed by policy. Network Operators would benefit from harmonizing multiple congestion signaling methods by policy or scope deployments to avoid conflicting feedback. 4. Security Considerations Security considerations are included separately in the SCONE protocol documents. 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 [_4G-Arch] 3GPP, "System Architecture for the Evolved Packet Core (EPC)", 1 June 2020, . Mishra, et al. Expires 11 August 2026 [Page 6] Internet-Draft SCONE Applicability & Manageability February 2026 [_5G-Arch] 3GPP, "System Architecture for the 5G System (5GS)", 7 January 2025, . 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 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 11 August 2026 [Page 7]