SCONE Privacy Properties and Incentives for Abuse

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 May 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The general problem statement for Standard Communication with Network Elements (SCONE) is described in the video optimization requirements document [I-D.joras-sconepro-video-opt-requirements], including the shaping or throttling that Communication Service Providers (CSPs) perform [ABR-Video-Shaping].¶

There were questions rasied at the IETF 119 BoF on SCONE 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.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. SCONE Context

SCONE is focusing on streaming video optimization use-cases through network-assisted application-level self-adaptation of media/video bit rate. SCONE 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 [ABR-Video-Shaping].¶

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 [I-D.ihlar-scone-masque-mediabitrate] and YouTube plan aware streaming [YouTube].¶

The SCONE network rate-limiting information (metadata) and the means of conveying the information is to be defined by the IETF.¶

4. Privacy Properties

This document section describes the privacy properties of the SCONE signal and considerations with regard to making the signal available to applications.¶

It is required that the SCONE 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 SCONE 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.¶

                 +-----+
                 | HSS |
                 +-----+
                    |
                 +-----+          +------+
                 | MME |          | PCRF |
                /+-----+\         +------+
               /         \            |
              /           \           |         ___  __
             /             \          |        /   )(  \
+----+   +-----+        +------+  +------+    (         )   +-----+
| UE |---| eNB |--------| S-GW |--| P-GW |---( Internet )---| CDN |
+----+   +-----+        +------+  +------+    (        _)   +-----+
                                               (__(___)

5. 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.¶

Note, why ECN is not suitable as a method to meet SCONE requirements is a separate topic, discussed in another document [I-D.tomar-sconepro-ecn], while the discussion below is focused on considering ECN operation only as an inspiration for properties SCONE signaling should have.¶

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 [RFC3168] and L4S ECN [RFC9330] [RFC9331] [RFC9332] 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 SCONE 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 SCONE signaling can throttle the application flow. Throttling may have a more negative impact on 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 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 SCONE 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 SCONE signals¶

6. Security Considerations

SCONE security considerations are discussed in the other documents covering specific network-to-host signaling methods and their implications. This document provides answers to questions regarding privacy of the SCONE signaling and metadata. There are no additional security considerations raised by this.¶

Other security considerations for SCONE signalling will be covered in separate Internet-Drafts (such as [I-D.joras-scone-quic-protocol]).¶

7. IANA Considerations

This document has no IANA actions.¶

8. References

Acknowledgments

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

• Spencer Dawkins¶

• Alan Frindell¶

• Bryan Tan¶

Authors' Addresses