Skip to main content

APIs To Expose SCONEPRO Metadata to Applications

Document Type Active Internet-Draft (individual)
Authors Wesley Eddy , Abhishek Tiwari , Alan Frindell
Last updated 2024-07-05
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
SCONEPRO                                                         W. Eddy
Internet-Draft                                                 A. Tiwari
Intended status: Informational                               A. Frindell
Expires: 6 January 2025                                             Meta
                                                             5 July 2024

            APIs To Expose SCONEPRO Metadata to Applications


   This document describes API considerations to provide applications
   with network-supplied information about acceptable network flow
   rates.  Since this information is expected to be signalled from the
   network within the stack below the application using the SCONEPRO
   protocol (to be defined by the IETF), it needs to be made accessible
   to applications in order for them to pick proper video rates, or to
   otherwise confine the application behavior within network-defined

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

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

   This Internet-Draft will expire on 6 January 2025.

Copyright Notice

   Copyright (c) 2024 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 (
   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

Eddy, et al.             Expires 6 January 2025                 [Page 1]
Internet-Draft                SCONEPRO APIs                    July 2024

   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.  SCONEPRO Background and Introduction  . . . . . . . . . . . .   2
     1.1.  SCONEPRO API Motivations  . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
   3.  Application Stack Designs . . . . . . . . . . . . . . . . . .   5
   4.  Potential SCONEPRO Metadata Provided By An API  . . . . . . .   7
     4.1.  Consideration of CTA Standards  . . . . . . . . . . . . .   7
   5.  Potential Browser API Extensions  . . . . . . . . . . . . . .   9
     5.1.  Potential Network Information API Inclusion . . . . . . .  10
     5.2.  Potential WebTrans API Inclusion  . . . . . . . . . . . .  10
     5.3.  Potential HLS/DASH Support  . . . . . . . . . . . . . . .  12
     5.4.  Other JavaScript API Options  . . . . . . . . . . . . . .  12
   6.  Potential QUIC API Inclusion  . . . . . . . . . . . . . . . .  12
     6.1.  Potential MoQ API Extension . . . . . . . . . . . . . . .  13
   7.  Potential OS APIs . . . . . . . . . . . . . . . . . . . . . .  13
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   10. Editor's Notes  . . . . . . . . . . . . . . . . . . . . . . .  15
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     11.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  SCONEPRO Background and Introduction

   Video traffic is already 70% of all traffic on the Internet and is
   expected to grow to 80% by 2028.  New formats like short form videos
   have seen tremendous growth in recent years.  Both in developed and
   emerging markets video traffic forms 50-80% of traffic on mobile
   networks.  These growth trends are likely to increase with new
   populations coming online on mobile-first markets and the observation
   that unlike text content, video content consumption is not being
   limited by literacy barriers.  On the other hand, the electromagnetic
   spectrum is a limited resource.  In order to ensure that mobile
   networks continue functioning in a healthy state despite this
   incredible growth, communication service providers (CSPs) will be
   required to make infrastructure investments such as more licensed
   spectrum, cell densification, massive MIMO etc.  In order to flatten
   the rate of growth, CSPs in several markets attempt to identify and
   throttle video traffic based on user data plans.  There are several
   problems with this kind of throttling:

Eddy, et al.             Expires 6 January 2025                 [Page 2]
Internet-Draft                SCONEPRO APIs                    July 2024

   1.  CSPs can not explicitly measure the effect that throttling has on
       the end user’s quality of experience (QoE) making this an open
       loop approach.

   2.  Traffic detection and throttling for every flow is compute
       intensive for CSPs.  With distributed UPF (user plane function)
       in 5G mobile networks more nodes in CSP network may need to
       support traffic detection and throttling.  Traffic detection can
       have inaccuracies and these inaccuracies are expected to increase
       as the content delivery industry moves towards end-2-end
       encryption like TLS 1.3 and encrypted client hello (ECH).

   3.  The unpredictable and non-transparent behavior of traffic
       throttlers used by CSPs confuse the bandwidth estimation and
       congestion control protocols being used within end-2-end video
       delivery sessions between content server and client.  This
       results in poor quality of experience (QoE) for the end user.

   4.  Content and Application Providers (CAPs) are designing algorithms
       to detect the presence of such traffic throttlers to counter
       their detrimental effects.  These algorithms have their own
       inaccuracies in detection and add compute resources on the CAP

   An alternative approach is for CAPs to self-adapt the traffic
   corresponding to video flows.  Since CAPs control the client and
   server endpoints and can measure end user QoE, they are in a better
   position to do this self-adaptation in a close loop manner.  This
   alternative approach has already been proven to improve user QoE in
   production deployments [YouTube].

   For this alternative approach to work a standardized secure on-path
   network interface is required which will enable CSP controlled
   network elements to signal the desired traffic profile
   characteristics to the CAP client/server endpoints.  The Secure
   Communication of Network Properties (SCONEPRO) protocol (previously
   known as SADCDN) is being proposed in the IETF as a working group
   [SADCDN-Charter] motivated by this alternate approach.

1.1.  SCONEPRO API Motivations

   The general problem statement for SCONEPRO is described in the video
   optimization requirements document
   [I-D.joras-sconepro-video-opt-requirements], including the shaping or
   throttling that CSPs perform.  While this problem currently has
   especially large impact on a few large content providers, solutions
   for SCONEPRO are generally applicable to any applications that use
   QUIC [RFC9000] and are subject to throttling within CSP networks.

Eddy, et al.             Expires 6 January 2025                 [Page 3]
Internet-Draft                SCONEPRO APIs                    July 2024

   General use of SCONEPRO metadata for any applications can be
   facilitated via an open Application Programming Interface (API) that
   could be implemented in appropriate QUIC stacks, web browsers, or
   other libraries.

   There are two aspects to consider for an API:

   1.  How will applications learn about network information that is
       discovered by SCONEPRO lower in the stack?  This is a primary
       consideration in this document.

   2.  How will applications signal their type (e.g. video streaming) or
       other relevant properties to the stack, to indicate that they are
       SCONEPRO-capable?  This is a secondary consideration in this
       document, because currently networks that perform throttling have
       built-in methods to implicitly determine the appropriate flows to

   Depending on how the SCONEPRO signaling protocol works (that is to-
   be-defined by the IETF), the SCONEPRO metadata may be available at
   various different places in the protocol stack spanning operating
   system, browser, and application code.  This document tries to
   initially make no assumptions about how the SCONEPRO signalling
   works, and so considers possibilities to integrate the metadata into
   APIs provided from OSes, QUIC libraries, web browsers, etc.  There
   are open questions at the moment about SCONEPRO signaling via on-path
   devices, what type of information is conveyed, and how it is
   represented.  The API capabilities may be limited by the protocol
   decisions, and realistic concerns about signaling across network
   domain boundaries, etc.

   During early SCONEPRO discussions, there have been suggestions that
   the API might take inspiration from Explicit Congestion Notification
   (ECN), as ECN also exposes information from the network (congestion
   experienced codepoints) to end hosts, and the design contends with
   potential for abuse, crosses network domain boundaries, and has other
   desirable properties.  Some key differences from ECN in usage
   relavent to a SCONEPRO API have been pointed out:

   1) ECN information is consumed either by transport protocols (e.g.
   TCP, MPTCP, and SCTP) or congestion control algorithms operating
   above e.g.  UDP or UDP-Lite [RFC8303] [RFC8304], but typically below
   an application.  For instance, within QUIC stacks used for video
   streaming, ECN can be consumed by the QUIC congestion control, but is
   not exposed to the application.

Eddy, et al.             Expires 6 January 2025                 [Page 4]
Internet-Draft                SCONEPRO APIs                    July 2024

   2) The exposure of SCONEPRO metadata is intended to be at the level
   of data flows (e.g. to aid application decisions about what media
   quality to fetch), whereas ECN is consumed at the level of packets
   (within an individual flow).

   While ECN is not a solution for SCONEPRO [I-D.tomar-sconepro-ecn], it
   is productive to consider as an example based on similarities,

   *  Signaling is coming from the network, and may cross different
      network domains.

   *  Signaling points can also drop packets, and the signaling
      participation is indtended to avoid excessive packet drops.

   The purpose of this document is only to demonstrate that general API
   exposure of the SCONEPRO metadata is achievable without prescribing a
   specific API solution.  It is envisioned that one or more specific
   API solutions will be defined either through IETF or W3C, to
   correspond with the SCONEPRO protocol specification.  At least in its
   current form, this document is not intended to be published as an

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Application Stack Designs

   There are a variety of different application stack designs that are
   relevant.  The main assumption for SCONEPRO in general is that QUIC
   is used.

   Applications could, for instance, either use QUIC directly through a
   linked software library, or applications could be running within a
   browser, using QUIC indirectly via browser APIs.

   Specific protocol solutions for SCONEPRO will be defined by the
   working group.  In general, the SCONEPRO network rate-limiting
   information could be discovered by an end-system in several different
   ways; potential network signaling approaches are described in other
   documents (e.g.  [I-D.ihlar-masque-sconepro-mediabitrate],
   [I-D.brw-sconepro-rate-policy-discovery], or others).  General
   classes of information signaling include:

Eddy, et al.             Expires 6 January 2025                 [Page 5]
Internet-Draft                SCONEPRO APIs                    July 2024

   1.  Via the QUIC stack, with the information inserted by an on-path
       SCONEPRO network element.

   2.  Via other IP or transport methods below QUIC (e.g.  IP extension
       headers, UDP options, etc.) that might be inserted on the path.

   3.  Via the OS, with the information coming in network advertisements
       separate from the transport connection (e.g. via Router
       Advertisements or DHCP).

   These methods are not necessarily mutually exclusive.  For instance,
   a DHCP option could indicate that certain classes of applications are
   throttled at a particular rate, while a SCONEPRO on-path mechanism
   could also provide more explicit per-connection indications of when
   throttling is active as well.

   | SCONEPRO       | Information | API Definitions                   |
   | Solution Type  | Visibility  |                                   |
   | QUIC-based     | QUIC        | Specific to each QUIC-library, or |
   |                | library or  | browser APIs.                     |
   |                | web browser |                                   |
   | IP or UDP-     | OS and      | Socket API extension may be       |
   | based          | possibly    | needed, e.g. to expose via socket |
   |                | QUIC        | options or other means.  For      |
   |                | library     | mobile apps using native stacks,  |
   |                |             | OS extensions may be needed.      |
   | Other          | OS          | Per-OS and/or socket API          |
   | approaches     |             | extensions                        |
   | that are not   |             |                                   |
   | on-path or     |             |                                   |
   | per-connection |             |                                   |

                                 Table 1

   For solution types that are not QUIC-based, the QUIC implementation
   could use socket or OS API extensions in order to get the data and
   convey it up to the applications via its own API.  However, QUIC
   library APIs are not standardized; they differ between common QUIC
   libraries, and so this document only suggests in a general sense of
   how the QUIC stack should convey this information to applications.

Eddy, et al.             Expires 6 January 2025                 [Page 6]
Internet-Draft                SCONEPRO APIs                    July 2024

   The following sections consider first the types of metadata that
   could be provided, and then how that SCONEPRO metadata might be
   provided in different cases of APIs including potential:

   1.  Browser APIs

   2.  QUIC APIs

   3.  OS APIs

4.  Potential SCONEPRO Metadata Provided By An API

   There are existing collections of metadata that are available for
   some types of adaptive rate streaming.  Examples include those
   defined by the CTA-5004 specification [CTA-5004] and CTA-5006
   specification [CTA-5006], which standardize JSON objects or HTTP
   headers conveyed by streaming media clients and servers respectively.
   These CTA specifications are also expected to be usable by

   Another example that could be built upon is the proposed flow
   metadata identifying the DownlinkBitrate

4.1.  Consideration of CTA Standards

   Several of the use cases defined by CTA-5006 are relevant, including:

   *  Provide an estimate of the throughput available between an edge
      server and a player, such that the player can use that information
      to enrich its decision about which bitrate to select, especially
      the initial bitrate decision made at the start of playback.

   *  Provide a means for a CDN to instruct all connected players to
      limit their upper bitrate, in response to an ISP request to reduce
      congestion on the last-mile network.

   *  Allow a CDN to signal to a player a suggested playback bitrate in
      order to optimize collective QoE.

   The "CDN" notion could be replaced with an ISP's on-path throttling

   As a specific example of metadata for SCONEPRO, CTA-5004 allows
   clients to indicate multiple types of rate metadata that are related
   to adaptive coded rate selection in the face of throttling.  Which of
   these options are used depends upon the client, but could be one of:

Eddy, et al.             Expires 6 January 2025                 [Page 7]
Internet-Draft                SCONEPRO APIs                    July 2024

   | CTA Data   | Units    | CTA Description                          |
   | Measured   | Integer  | The throughput between client and        |
   | Throughput | kilobits | server, as measured by the client and    |
   |            | per      | MUST be rounded to the nearest 100 kbps. |
   |            | second   | This value, however derived, SHOULD be   |
   |            | (kbps)   | the value that the client is using to    |
   |            |          | make its next Adaptive Bitrate switching |
   |            |          | decision.  If the client is connected to |
   |            |          | multiple servers concurrently, it must   |
   |            |          | take care to report only the throughput  |
   |            |          | measured against the receiving server.   |
   |            |          | If the client has multiple concurrent    |
   |            |          | connections to the server, then the      |
   |            |          | intent is that this value communicates   |
   |            |          | the aggregate throughput the client sees |
   |            |          | across all those connections.            |
   | Requested  | Integer  | The requested maximum throughput that    |
   | maximum    | kbps     | the client considers sufficient for      |
   | throughput |          | delivery of the asset.  Values MUST be   |
   |            |          | rounded to the nearest 100 kbps. ...     |
   |            |          | Note: This can benefit clients by        |
   |            |          | preventing buffer saturation through     |
   |            |          | over-delivery ...                        |

                                 Table 2

   The CTA-5006 also allows the server to convey a maximum suggested

    | CTA Data  | Units   | CTA Description                           |
    | Max       | Integer | The maximum bitrate value that the player |
    | suggested | kbps    | SHOULD play in its Adaptive Bit Rate      |
    | bitrate   |         | (ABR) ladder.  If the player is playing a |
    |           |         | bitrate higher than this value, it SHOULD |
    |           |         | immediately switch to a bitrate lower     |
    |           |         | than or equal to this value.              |

                                  Table 3

   There are two high-level approaches that might be viable in reusing
   CTA data types within an API that supports SCONEPRO:

Eddy, et al.             Expires 6 January 2025                 [Page 8]
Internet-Draft                SCONEPRO APIs                    July 2024

   1.  Append entire CTA-defined objects as optional components of
       dictionary or other data structures used in APIs, e.g. as a
       "cta5005" object that would be able to fully convey all of the
       CTA-defined metadata.

   2.  Append only selected fields from the CTA specs, reusing the
       definitions, but only including specific items of interest for
       SCONEPRO's problem statement, and leaving other CTA-defined
       metadata to be conveyed through the existing CTA-defined methods.

   The API can be agnostic to how the data is conveyed between network
   or on-path SCONEPRO devices and either clients or servers, but the
   same API can convey the information to the applications, regardless
   of how the network signaling works.  The semantics of the maxium
   suggested bitrate from the CTA-5006 match the needed semantics most
   closely, though since it is for an ABR ladder, it should be described
   carefully to apply the proper bitrate definition that the throttler
   is using for "on the wire" packets (including header overhead, etc.)
   versus the pure media payload stream bitrate.

5.  Potential Browser API Extensions

   For browser applications, there are multiple different browser APIs
   that might be extended to include SCONEPRO metadata; notably

   *  W3C Network Information

   *  WebTransport using QUIC

   *  HTTP Live Streaming (HLS) or Dynamic Adaptive Streaming over HTTP
      (DASH) client libraries

   *  Any Javascript HTTP requests that directly or indirectly use

   In either of these cases, the corresponding W3C API definitions are
   the proper place for actual definition of API extensions, and this
   document is merely exploring possibilities.

   The exploration is primarily around the ability to convey SCONEPRO
   signaling information that is discovered from the network path up to
   applications.  In addition, to indicate an application's desire to
   use SCONEPRO signaling in the first place, some small API extension
   is also be required, unless relying totally on the underlying stack
   or network to infer which flows should be receiving SCONEPRO
   treatment (e.g. as networks already infer which flows to throttle).

Eddy, et al.             Expires 6 January 2025                 [Page 9]
Internet-Draft                SCONEPRO APIs                    July 2024

5.1.  Potential Network Information API Inclusion

   The W3C Network Information API [W3C-NetInfo] is supported to some
   extent by several, but not all, common web browsers today.  It
   provides the possibility for an appliction to determine what
   underlying connection types or "effective" connection types (e.g.
   cellular. bluetooth, etc.) may be in use, with a corresponding set of
   performance parameter estimates including:

   *  Round Trip Time (RTT) in milliseconds providing a delay estimate.

   *  downlink in megabits per second providing an effective bandwidth
      estimate based on recently observed application layer throughput
      or properties of the underlying connectivity technology.

   *  downlinkMax in megabits per second representing an upper bound on
      the downlink speed of the first network hop, based on the
      underlying connectivity technology.

   The downlink and downlinkMax could be leveraged as places to put the
   SCONEPRO-discovered rate limit for an application, since anything
   greater than the SCONEPRO-discovered rate would not be expected to be
   usable for the application.

   Alternatively, another field could be added to the NetworkInformation
   interface in order to specifically provide the SCONEPRO metadata.

   In any case, a good property of the Network Information API is that
   an application can hook event handlers to be notified of changes, so
   that if there are limits that kick-in or are lifted midway into an
   application's lifetime (e.g. due to some mobility, etc.), the
   application will be able to be easily notified and adapt.

5.2.  Potential WebTrans API Inclusion

   In the future, WebTransport (WEBTRANS) might be used by SCONEPRO's
   targeted types of applications, such as browser-based adaptive
   streaming.  The IETF WEBTRANS working group is liasing with W3C as
   the IETF defines the protocol specification, whereas the W3C defines
   the API to use it.  This case is similar to the IETF RTCWEB and W3C
   WebRTC WG coordination in the past.  The same model of collaboration
   between IETF and W3C should work for SCONEPRO metadata, and the
   information provided could be discussed with the WEBTRANS WG in the
   IETF and notified to the W3C later, either through common
   participation and/or formal liason statement.

Eddy, et al.             Expires 6 January 2025                [Page 10]
Internet-Draft                SCONEPRO APIs                    July 2024

   The existing WebTrans API definition from W3C includes a "getStats()"
   method, that is defned in order to asynchronously gather and report
   statistics for a WebTransport underlying connection.  It returns a
   WebTransportConnectionStats object that is defined as a dictionary,
   including a number of items such as:

   *  bytesSent

   *  packetsSent

   *  bytesLost

   *  packetsLost

   *  bytesReceived

   *  packetsReceived

   *  smoothedRtt

   *  rttVariation

   *  minRtt

   *  WebTransportDatagramStats datagrams

   *  estimatedSendRate

   The estimatedSendRate is an unsigned long long, in bits per second,
   calculated by the congestion control algorithm in the user agent.
   This would be in the "upstream" direction to a CSP, though, rather
   than the "downstream" from a CSP, so is not useful to a client
   application in receiving indication of a downstream throttling rate
   from the network.

   Since other measurements are already included and the
   WebTransportConnectionStats is a dictionary, it seems natural to
   extend it to include additional optional fields, such as an allowed
   media rate, or other types of fields providing the application
   information that the underlying host or stack have discovered about
   the presence of throttling or explicit signaling of allowed media
   rate on a path.

Eddy, et al.             Expires 6 January 2025                [Page 11]
Internet-Draft                SCONEPRO APIs                    July 2024

   Such extensions might be including at a "MAY" level of conformance
   statement (rather than "SHALL" as used by all of the currently-
   defined information elements), as the allowed media rate will not be
   universally present or even useful for all WebTransport applications.
   Alternatively, it could be set to a "null" value similar to how the
   estimatedSendRate is sent when it is unknown by the user agent.

5.3.  Potential HLS/DASH Support

   Client libraries for HLS and DASH will use the underlying Javascript
   APIs or other underlying APIs, and might rely on them for SCONEPRO
   metadata support, as discussed in the next subsection.

5.4.  Other JavaScript API Options

   Typical HTTP adaptive streaming applications using existing browser
   API options would be ideal to support as directly as possible.  There
   are different ways to transfer HTTP/3 data provided to JavaScript
   applications that might be applicable.

   For instance, things like jQuery.ajax() or the "Fetch" API may be
   used.  In this case, there is little or no information about the
   network path state provided, though there are either jqXHR or
   Response objects returned that (for instance) allow HTTP headers to
   be conveyed, and in both cases could be extended to include SCONEPRO
   metadata.  These are returned at the completion of the HTTP transfer,
   however.  It might be more difficult to support more dynamic updates
   such as providing the metadata to an application mid-transfer so that
   an application might quickly switch to other media rates for future
   video segments being pre-fetched.

6.  Potential QUIC API Inclusion

   While there are no standard QUIC APIs, and there are multiple
   different styles in use, many QUIC implementations include objects in
   the API that represent the QUIC connections directly, and allow
   setting callbacks for connection-related events, or allow direct
   querying of connection state.  SCONEPRO metadata could either be
   supported as a type of callback event, triggered when the metadata is
   received, or it could be included within other connection state in a
   polled or interrogated data structure.

   Other QUIC implementations may leave I/O and management of sockets or
   other aspects to the application, external to the QUIC library.  In
   this case:

Eddy, et al.             Expires 6 January 2025                [Page 12]
Internet-Draft                SCONEPRO APIs                    July 2024

   1.  If the SCONEPRO metadata is visible as part of the QUIC
       connection, then it could be provided through the QUIC
       implementation's API.

   2.  If the SCONEPRO metadata is visible to the OS or as part of a
       socket API, it could be provided to the application via the
       underlying OS or socket abstraction libraries used by

   Regarding identification of the application flow type, options for a
   QUIC API may include adding "SCONEPRO-capable" type of flag or an
   optional flow-type tag that can be set by applications.  Compared to
   the complexity of existing QUIC APIs, these could be small additions.

6.1.  Potential MoQ API Extension

   While Media over QUIC (MoQ) is being defined, it is intended for
   media streaming over QUIC, which might be applicable to SCONEPRO, in
   case adaptive rate streams are detected and throttled by CSPs.  As
   yet, there is no standard MoQ API, an MoQ session is currently scoped
   either to a QUIC connection or a WebTransport session, so it should
   not be difficult to expose information learned by either transport
   stack to MoQ applications.  Since MoQ applications are media flows,
   it may be very simple for an application flow type to be conveyed or
   inferred via an eventual MoQ API..

7.  Potential OS APIs

   If SCONEPRO signaling is implemented via QUIC packets, this section
   is likely to be moot.  OS APIs would only be important to consider
   for SCONEPRO metadata to be exposed in the cases that it is
   discovered through some lower-level possibilities such as IP
   extension headers or options, UDP options, DHCP, etc.

   In applicable cases, the OSes supporting SCONEPRO might extend their
   sets of socket options to support a getsockopt that permits reading
   SCONEPRO-received metadata, such as a maximum bit rate.  Another
   possibility would be to allow such information to be retrieved via an
   ioctl on relevant sockets.  Several popular libraries and higher-
   level languages wrap system calls like getsockopt and ioctl already,
   and could be extended to include SCONEPRO metadata.  The "cmsg"
   interface [RFC2292] provices an example of how complex sets of
   ancillary data can be exchanged between applications and an OS kernel
   consistent with the way that socket options are implemented.

Eddy, et al.             Expires 6 January 2025                [Page 13]
Internet-Draft                SCONEPRO APIs                    July 2024

   A challenge might be that the application would likely need to
   periodically poll the OS for this information, as there may not be a
   general way to register a callback or hander for when the OS notices
   a change.  This may be one reason, among others, why supporting
   SCONEPRO signaling via the QUIC connection itself is more desirable.

   Another challenge relates to information such as a maximum rate per
   flow type discovered via DHCP or other means.  In that case, it may
   be difficult for the application to know how the network will
   actually classify its packets, and so it may not be clear what rate
   is relevant to assume.  This could be another argument favoring QUIC-
   based signaling, in terms of applications being able to directly make
   productive use of the information.

8.  Security Considerations

   General SCONEPRO security considerations are discussed in the other
   documents covering specific network-to-host signaling methods.
   Privacy concerns have also been discussed in

   Existing APIs that expose information about the network path to
   applications have documented security considerations, especially with
   regard to user privacy.  For instance, there may be concerns that
   such information can be used to assist in fingerprinting users,
   defeating anonymization, or otherwise exposing more information about
   the user to the application than the user might explicitly consent
   to.  Such concerns have been document, for example, with regard to
   the Network Information API.

   By providing additional information about throttling rate limits
   within the path, SCONEPRO could increase the amount of information
   availble on top of that provided by the current APIs.  For instance,
   if the rate information is very fine-grained, it could be useful in

   Generally, however, the CSP throttling information is currently very
   coarse grained, as it is used today.  Additionally, the application
   providers authenticate their users, and their is not an expectation
   of anonymity in popular platforms today.

   Beyond this, it is also the case that information provided by
   SCONEPRO can already be learned by CAP endpoints through various
   other mechanisms (e.g. the effect of on-path throttlers is clearly
   visible by observing application traffic packet flows).  SCONEPRO
   simply makes the signaling explicit, rather than requiring it to be
   observed and inferred separately.

Eddy, et al.             Expires 6 January 2025                [Page 14]
Internet-Draft                SCONEPRO APIs                    July 2024

9.  IANA Considerations

   This document has no IANA actions.

10.  Editor's Notes

   This section to be removed prior to any potential publication within
   an RFC.

   *  The "CSP" term is overloaded, especially with regard to web
      technology, and might be changed to "carrier", "network operator",
      etc. in the future, but would need to be consistent with
      terminology in other SCONEPRO documents.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,

11.2.  Informative References

   [CTA-5004] CTA, "Web Application Video Ecosystem - Common Media
              Client Data", September 2020.

   [CTA-5006] CTA, "Common Media Server Data", November 2022.

              Boucadair, M., Wing, D., Reddy.K, T., Rajagopalan, S.,
              Mishra, G. S., Amend, M., and L. M. Contreras, "Discovery
              of Network Rate-Limit Policies (NRLPs)", Work in Progress,
              Internet-Draft, draft-brw-sconepro-rate-policy-discovery-
              02, 3 July 2024, <

Eddy, et al.             Expires 6 January 2025                [Page 15]
Internet-Draft                SCONEPRO APIs                    July 2024

              Ihlar, M. and M. Kühlewind, "MASQUE extension for
              signaling media bitrate", Work in Progress, Internet-
              Draft, draft-ihlar-masque-sconepro-mediabitrate-00, 9
              February 2024, <

              Joras, M., Tomar, A., Tiwari, A., and A. Frindell,
              "SCONEPRO Video Optimization Requirements", Work in
              Progress, Internet-Draft, draft-joras-sconepro-video-opt-
              requirements-00, 17 May 2024,

              Rajagopalan, S., Wing, D., Boucadair, M., Reddy.K, T., and
              L. M. Contreras, "Flow Metadata for Collaborative Host/
              Network Signaling", Work in Progress, Internet-Draft,
              draft-rwbr-sconepro-flow-metadata-02, 26 June 2024,

              Tomar, A., Ihlar, M., Eddy, W., Swett, I., Tiwari, A., and
              M. Joras, "SCONEPRO Need for Defining A New On-Path
              Signaling Mechanism", Work in Progress, Internet-Draft,
              draft-tomar-sconepro-ecn-01, 23 May 2024,

              Tomar, A., Eddy, W., Tiwari, A., and M. Joras, "SCONEPRO
              Privacy Properties and Incentives for Abuse", Work in
              Progress, Internet-Draft, draft-tomar-sconepro-privacy-02,
              27 June 2024, <

   [RFC2292]  Stevens, W. and M. Thomas, "Advanced Sockets API for
              IPv6", RFC 2292, DOI 10.17487/RFC2292, February 1998,

   [RFC8303]  Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of
              Transport Features Provided by IETF Transport Protocols",
              RFC 8303, DOI 10.17487/RFC8303, February 2018,

Eddy, et al.             Expires 6 January 2025                [Page 16]
Internet-Draft                SCONEPRO APIs                    July 2024

   [RFC8304]  Fairhurst, G. and T. Jones, "Transport Features of the
              User Datagram Protocol (UDP) and Lightweight UDP (UDP-
              Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018,

              "SADCDN Working Group Charter", 14 May 2024,

              W3C, "The Network Information API", 11 May 2020,

   [YouTube]  YouTube, "YouTube Plan Aware Streaming", 21 March 2024,


   This document represents collaboration and inputs from others,

   *  Anoop Tomar

   *  Matt Joras

   *  Bryan Tan

   Additional, helpful critique and comments were provided by:

   *  Lucas Pardue

   *  Ted Hardie

   *  Michael Welzl

   *  Gorry Fairhurst

   *  Brian Trammell

Authors' Addresses

   Wesley Eddy

Eddy, et al.             Expires 6 January 2025                [Page 17]
Internet-Draft                SCONEPRO APIs                    July 2024

   Abhishek Tiwari

   Alan Frindell

Eddy, et al.             Expires 6 January 2025                [Page 18]