]> Meta

wesleyeddy@meta.com

Meta

atiwari@meta.com

Meta

afrind@meta.com

Web and Internet Transport SCONE Adaptive Bit-Rate Video 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 SCONE protocol signalling, 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 limits.

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

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

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 . 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 Standard Communication with Network Elements (SCONE) protocol (previously known as SADCDN and SCONEPRO) is an IETF working group motivated by this alternate approach.

SCONE API Motivations The general problem statement for SCONE is described in the video optimization requirements document , including the shaping or throttling that CSPs perform. While this problem currently has especially large impact on a few large content providers, solutions for SCONE are generally applicable to any applications that use QUIC and are subject to throttling within CSP networks. General use of SCONE 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 SCONE 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 SCONE-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 throttle.

The SCONE metadata may be available at different places in the protocol stack implementation spanning operating system, QUIC library, browser, and application code. This document tries to initially make no assumptions about how the SCONE 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 SCONE 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 SCONE 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 SCONE 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 , 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. 2) The exposure of SCONE 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 SCONE , it is productive to consider as an example based on similarities, including:

• 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 SCONE 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 SCONE protocol specification. At least in its current form, this document is not intended to be published as an RFC.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Application Stack Designs There are a variety of different application stack designs that are relevant. The main assumption for SCONE in general is that QUIC is used. Applications could, for instance, (1) include their own QUIC implementation, (2) use QUIC directly through a linked software library, or (3) run within a web browser, using QUIC more indirectly via browser APIs. The SCONE working group is defining the signalling protocol ). as part of the QUIC stack, with the information inserted by an on-path SCONE network element. Other approaches that do not seem to be as actively pursued at the moment are: (1) signaling via other IP or transport methods below QUIC (e.g. IP extension headers, UDP options, etc.) that might be inserted on the path, and (2) signaling via the OS, with the information coming in network advertisements separate from the transport connection (e.g. via Router Advertisements or DHCP). Therefore, OS-provided APIs and socket API extensions are not considered further in this document, since signaling is assumed to be implemented using QUIC. It is important to note that 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.

Potential SCONE Metadata Provided By An API SCONE is chartered to provide "throughput advice". The SCONE protocol encodes the rate signal in a QUIC packet field that may be periodically updated. The protocol currently discusses the expectations on lifetime or validity time of the rate signals and update behavior. The remainder of this document considers API extensions in general to provide SCONE data, whether it be a single data rate, or more comprehensive characterization.

Potential Browser API Extensions For browser applications, there are multiple different browser APIs that might be extended to include SCONE metadata; notably including:

• 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 HTTP/3.

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 SCONE signaling information that is discovered from the network path up to applications. In addition, to indicate an application's desire to use SCONE 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 SCONE treatment (e.g. as networks already infer which flows to throttle).

Potential Network Information API Inclusion The W3C Network Information API 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 SCONE-discovered rate limit for an application, since anything greater than the SCONE-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 SCONE 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.

Potential WebTrans API Inclusion In the future, WebTransport (WEBTRANS) might be used by SCONE'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 SCONE 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. 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. 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.

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 SCONE metadata support, as discussed in the next subsection.

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

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. SCONE 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. Regarding identification of the application flow type, options for a QUIC API may include adding "SCONE-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.

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

Security Considerations General SCONE 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, SCONE 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 fingerprinting. 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 SCONE 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). SCONE simply makes the signaling explicit, rather than requiring it to be observed and inferred separately.

IANA Considerations This document has no IANA actions.

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

References Normative References This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References AT&T AT&T AT&T The SCONE protocol requires a semantically consistent way for CSPs to convey a throughput advice. The Video Session Data Rate (VSDR) describes the formula to be applied both for setting the limit on the CAP side as well as for the CSP to validate conformance with the policy. Mozilla Private Octopus Inc. Fastly Meta Ericsson This document describes a protocol where on-path network elements can give endpoints their perspective on what the maximum achievable throughput might be for QUIC flows. Meta Platforms, Inc. Meta Platforms, Inc. Meta Platforms, Inc. Meta Platforms, Inc. These are the requirements for the "Video Optimization" use-case for the SCONE topic, which broadly speaking seeks to optimize video playback experience in mobile networks by cooperative communication between video content providers and the providers of network services to end users. Meta Ericsson Meta Google Meta Meta This document discusses the need for defining a new on-path signaling mechanism and addresses the question “why can't we use Explicit Congestion Notification (ECN)” for the SCONE use-case. The SCONE objective is to optimize user QoE for streaming media/video services through network assisted application-level self-adaptation. This requires a Communication Service Provider’s (CSP’s) network device to send streaming media/video traffic profile characteristics (e.g. for allowed average media/video bit-rate, burst rate etc.) with the client application endpoint to enable content self adaptation implementations by content application providers (CAPs). Meta Meta Meta Meta This document discusses privacy properties of the SCONE metadata or network-to-host signals. This covers questions that were raised during the IETF 119 BoF and subsequent discussions. It is not intended to be published as a separate RFC but might be incorporated as a part of the security considerations or other content within eventual SCONE RFCs together with other documents covering security considerations. Other documents will address additional aspects of the security considerations for SCONE metadata. This document describes how the transport protocols Transmission Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP), and Lightweight User Datagram Protocol (UDP-Lite) expose services to applications and how an application can configure and use the features that make up these services. It also discusses the service provided by the Low Extra Delay Background Transport (LEDBAT) congestion control mechanism. The description results in a set of transport abstractions that can be exported in a transport services (TAPS) API. This is an informational document that describes the transport protocol interface primitives provided by the User Datagram Protocol (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols. It identifies the datagram services exposed to applications and how an application can configure and use the features offered by the Internet datagram transport service. RFC 8303 documents the usage of transport features provided by IETF transport protocols, describing the way UDP, UDP-Lite, and other transport protocols expose their services to applications and how an application can configure and use the features that make up these services. This document provides input to and context for that document, as well as offers a road map to documentation that may help users of the UDP and UDP-Lite protocols. YouTube

Acknowledgments This document represents collaboration and inputs from others, including:

• Anoop Tomar
• Matt Joras
• Bryan Tan

Additional, helpful critique and comments were provided by:

• Lucas Pardue
• Ted Hardie
• Michael Welzl
• Gorry Fairhurst
• Brian Trammell