]> Meta

anooptomar@meta.com

Meta

wesleyeddy@meta.com

Meta

atiwari@meta.com

Meta

mjoras@meta.com

Web and Internet Transport SCONEPRO Privacy This document discusses privacy properties of the SCONEPRO 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 SCONEPRO RFCs together with other documents covering security considerations. Other documents will address additional aspects of the security considerations such as authentication, integrity protection, and encryption of SCONEPRO metadata.

Introduction The general problem statement for Secure Communication of Network Properties (SCONEPRO) is described in the video optimization requirements document , including the shaping or throttling that Communication Service Providers (CSPs) perform . There were questions rasied at the IETF 119 BoF on SCONEPRO regarding privacy considerations, include:

1. What are the privacy properties of the SCONE signal? If making the signal available to applications is the goal, does that have unwanted properties?
2. Can the signal be designed so that there is no incentive to fake it, similar to ECN?

This document provides additional context necessary, and then directly addresses these questions.

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.

SCONEPRO Context SCONEPRO is focusing on streaming video optimization use-cases through network-assisted application-level self-adaptation of media/video bit rate. SCONEPRO addresses the following high-level problem statement:

1. Currently Communication Service Provider (CSP) networks (mainly cellular and satellite networks) perform bit-rate throttling (either 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 towards radio base-stations in downlink direction;
   • To limit the overall capacity/bandwidth required and to manage capex requirements (e.g. need for more RF spectrum and deployment of more radio base-stations), etc.
2. To perform throttling, CSP networks need to detect streaming video flows, which uses deep packet inspection and trial decryption of QUIC initial packets in order to decode and read the Server Name Indication (SNI) field present in initial ClientHello messages. This requires significant compute resources. Throttling (shaping or policing) also requires nontrivial compute and memory resources. For details refer to .
3. Throttling in the CSP network has a significant negative impact on streaming video application quality of experience (QoE), and it also degrades mobile User Equipment (UE) battery performance.
4. An equivalent reduction in network traffic can be achieved more intelligently via self-adaptation by Content Application Providers (CAPs), because CAPs can actually measure QoE parameters and can tune their self adaptation strategy much more effectively than the QoE-blind approach taken by CSP's network throttlers. Hence, this approach of self-adaptation by CAPs is much superior in terms of end user QoE compared to CSP-led network throttling.
5. CSPs currently use intentional (artificial) network throttling as a way to create service differentiation between users on different payment plans and to enforce fair usage plans.
6. CAPs do not and should not have access to subscriber payment plan information.
7. There is a need for a solution to the above multi-objective optimization problem which achieves both: (a) superior user QoE, and (b) differentiated data limitation consistent with subscriber plans.
8. One potential solution to this problem is self-adaptation of video sessions by CAPs. Since the subscriber plan information must live within the CSP network domain, the CSP network can abstract out the different traffic profiles suited to different subscriber plans and provide the abstracted information to application-clients running on the UEs for CAP self-adaptation implementations.

For details, refer to the proof of concept trial and YouTube plan aware streaming . The SCONEPRO network rate-limiting information (metadata) and the means of conveying the information is to be defined by the IETF.

Privacy Properties This document section describes the privacy properties of the SCONEPRO signal and considerations with regard to making the signal available to applications. It is required that the SCONEPRO signal shall not carry information that includes either:

• Any Personal Identifiable Information (PII) that can be used to identify the subscriber such as International Mobile Subscriber Identity (IMSI). IMSI is a unique 15-digit number that identifies every user uniquely within a mobile network.
• Network’s policy associated with a subscriber - the CSP Network stores subscriber policies in network elements such as HSS (Home Subscriber Server)/UDM(Unified Data Management)/PCRF(Policy and Charging Rules function) to support various subscriber specific features in the network.

To help describe the SCONEPRO approach to meet these privacy requirements, as well as to ensure the signal does not have unwanted properties, the next subsections provide an example and then general approach.

Mobile Network Example Using a mobile network as a reference, the diagram in explains how CSP networks implement throttling to support different data rates based on the subscribers' data plans.

Mobile Network Data Flow

In order to perform throttling to enable different data-rates based on the subscribers’ data plans, the CSP network need to support following high-level functionalities:

1. Detect the streaming video flows.
2. Identify the bearer associated with the flow.
   • Bearer is a logical pipe between UE (Mobile phone) and P-GW (PDN Gateway) to carry packets belonging to one or more IP flows. IP flows (aka service data flows -SDFs) may belong to one or more services. All the service data flows within a bearer gets the same level of QoS.
3. Identify the subscriber who is using this service/flow by using mapping between bearer and subscriber ID (IMSI).
4. Extract the network’s policy associated with a subscriber.
5. Activate throttling to limit the flow’s bit-rate according to subscribers’ data plans.

This is performed in the network element which is on the data path and has access to the subscriber policies through standard interface with PCRF (Policy Charging and Rule function). In a 4G network this network-element is P-GW (PDN Gateway) and in a 5G network this network-element is UPF (User Plane Function). Note - UPF is not shown in above diagram as above diagram is for 4G mobile network. UPF is equivalent to P-GW in the 5G mobile network.

SCONEPRO's Approach To meet the privacy requirements as well as to ensure that signal does not have unwanted properties, SCONEPRO proposes following approach:

1. Use an on-path interface between the user's application end-point and network element to exchange the SCONEPRO signal. This should be the same on-path interface that has already been established between application end-point and network element to carry the video flow whose bit-rate needs to be regulated. Due to the usage of an on-path interface there is no need to exchange additional subscriber specific information (that could have been otherwise used to identify the subscriber) between CSP network and application end-point to establish association between the flow and scone signaling.
2. Network element to be involved in SCONEPRO signaling should be on data-path and should have access to the subscriber policies. This network element should calculate the target bit-rate for the specific flow based on subscribers’ data plan, network configuration & capacity and CSP network policy and share only the just enough information (for e.g. video/media bit-rate etc. Exact metadata and data-types to be defined during the solution definition phase of SCONEPRO) with application end-point via SCONEPRO signaling. This would ensure that SCONEPRO signal does not carry the network's policy associated with a subscriber and it does not carry unwanted network information/properties.

Note - Information such as video/media bit-rate, that is required to be shared by a network device with client application end-point using SCONEPRO signal can already be learnt by application end-point currently, through various mechanisms (the effect of on-path throttlers is clearly visible by observing application traffic by third party tools like PCAP). So as part of SCONEPRO scope we are not proposing, network to share any information with application endpoints which can not be known without SCONEPRO, rather objective is that such information be made explicit.

Incentives for Abuse In early discussion, at the IETF 119 BoF session, it was pointed out that possible incentives for abuse need to be considered, and that a good example existing network-to-host signalling case is Explicit Congestion Notification (ECN), for which the impact of both lying/cheating hosts and network devices has been analyzed, and for which there are no strong incentives for either hosts or network devices to unnecessarily forge or tamper with ECN codepoints. 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. In general both classic ECN and L4S ECN are mechanisms to send end-to-end notification of network congestion. And it relies on 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.

The case of SCONEPRO is similar in many ways to 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 SCONEPRO signaling can throttle the application flow. Throttling may have a more negative impact on application’s performance compared to using SCONEPRO 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 SCONEPRO signal.
• Regarding faking CE bit (either setting or clearing it), 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, faking SCONEPRO signaling (sending incorrect meta-data) there is no incentive because sending incorrect meta-data may have more negative impact on application’s performance within the network faking the SCONEPRO signals

Security Considerations General SCONEPRO security considerations are discussed in the other documents covering the problem statement and specific network-to-host signaling methods. This document provides answers to questions regarding privacy of the SCONEPRO signaling and metadata. There are no additional security considerations raised by this. Other security considerations such as authentication, integrity protection, and encryption of SCONEPRO signalling will be covered in separate Internet-Drafts.

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 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 SADCDN 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. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mjoras/sadcdn-video-optimization-requirements. YouTube

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

• Spencer Dawkins
• Alan Frindell
• Bryan Tan