



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,
              <https://datatracker.ietf.org/doc/draft-ietf-scone-
              protocol/>.

6.2.  Informative References

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



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,
              <https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3144>.

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]
