]> Meta

anooptomar@meta.com

Ericsson

marcus.ihlar@ericsson.com

Meta

wesleyeddy@meta.com

Google

ianswett@google.com

Meta

atiwari@meta.com

Meta

mjoras@meta.com

Web and Internet Transport SCONE ECN 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).

SCONE Background and Introduction Currently Communication Service Provider (CSP) networks (mainly cellular and satellite networks) perform bit-rate throttling (shaping or policing) of streaming video flows. The motivation behind throttling may vary across CSPs. For example, the motivation can be:

• To support different data-rates based on the subscribers’ data plans;
• To reduce egress (tonnage) towards radio base-stations in the downlink direction;
• To limit the overall capacity/bandwidth required and to manage CAPEX requirements (e.g. the needs for more RF spectrum and deployment of more radio base-stations);
• Or other reasons.

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, 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. CSPs currently use this throttling as a way to create service differentiation between users on different payment plans and to enforce fair usage 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. Throttling in the CSP network has a significant negative impact on streaming video application QoE and also degrades User Equipment (UE) battery performance.
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). To perform throttling, CSP networks need to detect streaming video flows, which needs deep packet inspection and trial decryption of QUIC initial packets in order to decode and read the Server Name Indication (SNI) field present in the ClientHello message. This requires significant compute resources and risks ossifying QUIC. The throttling (shaping or policing) itself also requires non-trivial compute and memory resources.
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. CAPs do not and should not have access to subscriber payment plan information, making these algorithms complex to create and maintain.

There is a need for a solution to these problems which achieves both superior user QoE for CAPs, along with supporting CSPs' needs for differentiated data limitations consistent with subscriber plans. 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. Early requirements for a technical solution based on this approach are described in , and the protocol that the IETF working group is defining is in .

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.

ECN Overview Explicit Congestion Notification (ECN) is an extension to the Internet Protocol. ECN allows end-to-end notification of network congestion without dropping packets. ECN is an optional feature that may be used between two ECN-enabled endpoints when the underlying network infrastructure also supports it.

ECN IP Header Bits ECN uses the two least significant (right-most) bits of the Traffic Class field in the IPv4 or IPv6 header to encode four different code points: 00 – Not ECN-Capable Transport, Not-ECT 01 – ECN Capable Transport(1), ECT(1) - For L4S ECN enabled Transport 10 – ECN Capable Transport(0), ECT(0) 11 – Congestion Experienced, CE. - To be set by a network element which can detect congestion in the link.

ECN Principles In general both classic ECN and L4S ECN RFC 9330 , RFC 9331 and RFC 9332 are mechanisms to send end-to-end notification of network congestion. Use of ECN relies on the following principles:

1. Sender to set the ECT code-points correctly for a particular flow.
2. Receiver to send the feedback back to the sender correctly based on CE value.
3. Network elements to set the CE bit correctly based on actual congestion conditions in the network.
4. ECN codepoints are not bleached or remarked within the network, other than to set the CE bit when appropriate.

Questions

Why can't we use ECN instead of defining a new SCONE signal? The CE bit in ECN is used by the network element to notify the application end-points about the congestion in the network. SCONE is addressing a use-case wherein the network element does “intentional throttling” (shaping/policing) due to various reasons as mentioned earlier in this document such as to create service differentiation between users on different payment plans, to enforce fair usage plans, and to reduce egress (tonnage) towards radio base-stations in downlink direction. In order to replace throttling by “application level self-adaptation” SCONE signaling is required to carry video/media bit-rate etc. between network element and application end-point (note: exact metadata and data-types are to be defined during the solution definition phase of SCONE) ECN signaling can not support this use-case due to reasons mentioned below:

• In the case of intentional throttling, CSP networks throttle the video flow to a fixed bit rate instantly. To replace the throttling in the network by “self bitrate adaptation”, the CSP network is required to send a specific video bitrate within SCONE signaling meta-data to enable instant convergence of flow’s bit rate to a specific bit-rate. This is not possible with ECN signaling.
• Throttling is a CSP’s policy-based restriction of the flow rather than a congestion-based one. Throttling is not based on queue occupancy, competing traffic, contention for bandwidth/radio-resource etc. SCONE signal is intended for application layer adaptation whereas ECN is designed for transport layer adaptation. Through ECN, the CSP network forces the sender's transport rate to be within a specific range, rather than communicating what the application layer media bitrate should be. This implies that usage of ECN will retain some of the negative effects of network shaping such as delaying the video startup time.
  • For example, a key part of the success of YouTube's Plan Aware Streaming is that YouTube could still burst at a much faster rate than the long term media bitrate. This is more efficient for CAPs’ servers, more efficient on client devices, and means CAPs can still use existing ABR algorithms, and just cap the quality based on the communicated long term bandwidth limit. This just isn't possible with ECN. If one allows sending 10 Mbps for some period of time, but not average, BBR is going to think it can send that fast and the ABR algorithm is going to upswitch and then both are going to have a poor experience when the delivery rate suddenly decreases. ECN avoids some packet loss, but otherwise it can't do anything fundamentally new.
• Congestion based ECN signaling is typically performed at the element which is next to the congested link so that it can detect congestion and set the CE bits accordingly. To enable subscriber’s data-plan based bit-rate signaling as well as to reduce egress towards radio base-stations in downlink direction for video streaming flows, SCONE signaling needs be performed at the element which has access to subscriber policy and which is hosted between radio base-stations and CDNs in downlink direction. In mobile networks this network element is PGW/UPF in 4G/5G networks.
• The primary targeted consumers of SCONE information are HTTP adptive bitrate video applications. The ABR decisions are typically made on the client side by the video player itself. While these players could in principle take something like ECN into account, this is not in line with current practices. There is no JavaScript API provided by browsers to get ECN information, and none of the most popular HTTP libraries used to build video players in mobile applications expose ECN information as part of their HTTP API. ECN is largely consumed by transport protocols (rather than applications) and actuated on by servers (rather than clients).
• SCONE information is intended to be per flow, not per-packet like ECN. Among typical transport protocols, only UDP and UDP-Lite support application access to the ECN bits (because other standard transport protocols typically implement congestion control themselves) , though implementations may vary in their capabilities. ECN APIs, where they exist, are at the socket layer for datagram protocols, and have semantic binding to given packets. This does not match with the SCONE needs to signal at the flow-level and for QUIC transport.
• ECN bits within the IP header will not be enough to carry the meta-data required to be exchanged between network element and client endpoint.
  • Note - In addition to SCONE, CAPs are actively exploring L4S, but CAPs don't believe that L4S addresses the use-case SCONE is trying to solve.

Can the SCONE signal be designed so that there is no incentive to fake it, like with ECN? Any network device which can alter ECN bits can simply drop the packets. And packet drop may have more negative impact on application’s performance compared to using ECN bits to indicate congestion in the network. Similarly any network device which can send SCONE signaling can throttle the application flow. Throttling may have a more negative impact on an application’s performance compared to using SCONE signaling to influence the incoming flow bit-rate from the sender. So like ECN, there should not be any incentive for the network device to fake the SCONE signal. Regarding falsely manipulating CE bit in ECN (either setting or clearing the CE bit), there is no incentive either way, because both cases may have more negative impact on application’s performance within the network faking the ECN signals Similarly, there is no incentive for faking SCONE signaling (sending incorrect meta-data) because sending incorrect meta-data may have more negative impact on an application’s performance within the network faking the SCONE signals.

Security Considerations General SCONE security considerations are discussed in the other documents covering the specific network-to-host signaling methods. This document only addresses questions regarding use of ECN for SCONE.

IANA Considerations This document has no IANA actions.

References Normative References 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 This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK] This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. A Transport Converter may provide conversion service for one or more TCP extensions. The conversion service is provided by means of the 0-RTT TCP Convert Protocol (Convert). This protocol provides 0-RTT (Zero Round-Trip Time) conversion service since no extra delay is induced by the protocol compared to connections that are not proxied. Also, the Convert Protocol does not require any encapsulation (no tunnels whatsoever). This specification assumes an explicit model, where the Transport Converter is explicitly configured on hosts. As a sample applicability use case, this document specifies how the Convert Protocol applies for Multipath TCP. <p>Open Caching architecture is a use case of Content Delivery Network Interconnection (CDNI) in which the commercial Content Delivery Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN). This document defines extensions to the CDNI Metadata Interface (MI) and the Footprint & Capabilities Advertisement interface (FCI). These extensions are derived from requirements raised by Open Caching but are also applicable to CDNI use cases in general.</p> This document describes the L4S architecture, which enables Internet applications to achieve low queuing latency, low congestion loss, and scalable throughput control. L4S is based on the insight that the root cause of queuing delay is in the capacity-seeking congestion controllers of senders, not in the queue itself. With the L4S architecture, all Internet applications could (but do not have to) transition away from congestion control algorithms that cause substantial queuing delay and instead adopt a new class of congestion controls that can seek capacity with very little queuing. These are aided by a modified form of Explicit Congestion Notification (ECN) from the network. With this new architecture, applications can have both low latency and high throughput. The architecture primarily concerns incremental deployment. It defines mechanisms that allow the new class of L4S congestion controls to coexist with 'Classic' congestion controls in a shared network. The aim is for L4S latency and throughput to be usually much better (and rarely worse) while typically not impacting Classic performance. This specification defines the protocol to be used for a new network service called Low Latency, Low Loss, and Scalable throughput (L4S). L4S uses an Explicit Congestion Notification (ECN) scheme at the IP layer that is similar to the original (or 'Classic') ECN approach, except as specified within. L4S uses 'Scalable' congestion control, which induces much more frequent control signals from the network, and it responds to them with much more fine-grained adjustments so that very low (typically sub-millisecond on average) and consistently low queuing delay becomes possible for L4S traffic without compromising link utilization. Thus, even capacity-seeking (TCP-like) traffic can have high bandwidth and very low delay at the same time, even during periods of high traffic load. The L4S identifier defined in this document distinguishes L4S from 'Classic' (e.g., TCP-Reno-friendly) traffic. Then, network bottlenecks can be incrementally modified to distinguish and isolate existing traffic that still follows the Classic behaviour, to prevent it from degrading the low queuing delay and low loss of L4S traffic. This Experimental specification defines the rules that L4S transports and network elements need to follow, with the intention that L4S flows neither harm each other's performance nor that of Classic traffic. It also suggests open questions to be investigated during experimentation. Examples of new Active Queue Management (AQM) marking algorithms and new transports (whether TCP-like or real time) are specified separately. This specification defines a framework for coupling the Active Queue Management (AQM) algorithms in two queues intended for flows with different responses to congestion. This provides a way for the Internet to transition from the scaling problems of standard TCP-Reno-friendly ('Classic') congestion controls to the family of 'Scalable' congestion controls. These are designed for consistently very low queuing latency, very low congestion loss, and scaling of per-flow throughput by using Explicit Congestion Notification (ECN) in a modified way. Until the Coupled Dual Queue (DualQ), these Scalable L4S congestion controls could only be deployed where a clean-slate environment could be arranged, such as in private data centres. This specification first explains how a Coupled DualQ works. It then gives the normative requirements that are necessary for it to work well. All this is independent of which two AQMs are used, but pseudocode examples of specific AQMs are given in appendices. Meta Platforms, Inc. Meta Platforms, Inc. Meta Platforms, Inc. Meta Platforms, Inc. These are the requirements for the "Video Optimization" use-case for the SCONEPRO 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. 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. YouTube

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

• Spencer Dawkins
• Alan Frindell
• Bryan Tan
• Michael Welzl
• Ted Hardie