# Change Request Summary: WT2c Updates to Secure Communication of Network Properties (SCONE-PRO)

## Document Information
- **CR Number**: 0032 (Rev 1)
- **Specification**: TS 26.804 v19.1.0
- **Category**: C (functional modification)
- **Release**: Rel-20
- **Work Item**: FS_AMD_Ph2 (Advanced Media Delivery Phase 2 Study)

## Purpose and Scope

This CR addresses Work Topic #2 (Server and Network-assisted media streaming) by documenting the impact of IETF's Standard Communication with Network Elements (SCONE) protocol on 5G Media Streaming. The CR updates the technical report to reflect the evolution from the initial SCONE-PRO BoF discussions to the established SCONE Working Group and its protocol development.

## Main Technical Contributions

### 1. References Update (Clause 2)

**New References Added:**
- **[X1]**: IETF draft-ietf-scone-protocol-04 - "Standard Communication with Network Elements (SCONE) Protocol"
- **[X2]**: IETF draft-eddy-tcpm-scone-01 - "SCONE TCP Option" (extends SCONE beyond QUIC to TCP)

### 2. Clause Title and Scope Changes (Clause 5.25.1.2 and 5.25.1.3)

**Structural Reorganization:**
- **Clause 5.25.1.2**: Changed from "void" to "Secure Communication of Network Properties (SCONE-PRO)" - now contains historical context and motivation
- **Clause 5.25.1.3**: Retitled from generic content to "Standard Communication with Network Elements (SCONE)" - focuses on current WG status and objectives

**Content Migration:**
- Historical SCONE-PRO BoF material moved to Clause 5.25.1.2
- Current SCONE WG charter and objectives documented in Clause 5.25.1.3
- Detailed technical protocol specification moved to new Annex C.3

### 3. New Annex C.3: Detailed SCONE Protocol Specification

This new annex provides comprehensive technical documentation of the SCONE protocol.

#### C.3.1 Introduction

**Historical Context:**
- Documents the evolution from SCONE-PRO BoF sessions (September 2024) to SCONE WG establishment (November 2024 at IETF 121)
- Preserves motivation material including:
  - ABR Video Shaping challenges
  - YouTube™ coordination examples with MNOs
  - Traffic shaping issues and their impact on user experience

**Problem Statement Summary:**
- Video traffic represents 70% of Internet traffic (projected 80% by 2028)
- 50-80% of mobile network traffic volume
- Network capacity augmentation not keeping pace with demand
- Traffic shaping negatively affects video quality without measurable QoE feedback
- ABR schemes struggle to converge with traffic shapers, causing "ping-pong" effects

**Core Solution Characteristics:**
- Flow associativity (per-QUIC connection)
- Single communication channel for client initiation and network properties
- Network-originated property signaling
- On-path establishment (no off-path elements required)
- Optional implementation
- Advisory properties (not mandatory directives)

**SCONE WG Objectives:**
1. Mechanism for rate-limiting network elements to communicate throughput advice
2. Application notification for both upstream/downstream traffic
3. Throughput advice as guideline (not congestion signal)
4. Dynamic updates capability
5. Endpoint signaling and acknowledgment requirements determination

**Implementation Progress:**
- Protocol draft adopted May 2025
- WG Last Call: December 19, 2025 - January 20, 2026
- Successful interoperability testing at IETF#123 hackathon (July 2025) with running code from Ericsson, Nokia, Meta, YouTube, Cloudflare
- Live demos at IETF#124 (November 2025) by Ericsson and Meta showing improved UX
- TCP extension draft available (SCONE-TCP)

#### C.3.2 SCONE Protocol Technical Details

**Protocol Principles:**
- **Encoding**: Throughput advice encoded in 6 LSBs of first octet
- **Logarithmic distribution**: Enables wide range representation
- **Packet insertion**: Sender occasionally inserts SCONE packet at UDP datagram beginning
- **No acknowledgment required**: Receiver doesn't need to ACK throughput advice
- **Advisory nature**: No enforcement mechanism

**Packet Format:**
- Illustrated in Figure C.3.2-1 (SCONE packet structure)

**Key Characteristics:**

1. **Independent of congestion signals**: Complements but doesn't replace traditional congestion control
2. **Unspecified scope**: Flexibility for network operators (single hop or multi-element)
3. **Per-flow signal**: Applies to specific QUIC flow (UDP 4-tuple)
4. **Unidirectional**: Direction-specific advice (upstream/downstream independent)
5. **Advisory only**: Optional, non-binding guidance
6. **Dynamic updates**: Continuous or periodic updates as conditions change

**Bitrate Calculation:**
- **Value 127**: Sent by QUIC endpoint or indicates unknown throughput advice
- **Values 0-126**: Represent rate ceiling from network elements
- **Logarithmic scale formula**:
  - Base rate (b_min) = 100 Kbps
  - Bitrate at value n = b_min × 10^(n/20)

**Packet Transmission:**
- Unencrypted transmission
- Typically standalone UDP packet
- Distinct SCONE packet format visible to network

**Network Element Behavior (Figure C.3.2-2):**
- Any on-path NE capable of rate-limiting may send throughput advice
- Multiple NEs can inject SCONE packets for same flow
- Each NE reports its own maximum allowable rate view
- No protocol-defined aggregation or coordination between NEs

**Early SCONE Notification:**
- Proactive client signaling mechanism
- Clients indicate SCONE capability before QUIC connection fully established
- Helps NEs detect SCONE-capable flows without DPI or QUIC Initial decryption
- "SCONE Indication" appended to QUIC Initial packet

**Monitoring Period:**
- **Standard period**: 67 seconds
- Defines time window over which throughput advice applies
- Flexible implementation:
  - Senders can limit rate over any period up to 67 seconds
  - NEs monitor/apply limits using minimum 67-second period

## Relationship to 5G Media Streaming

The CR maintains the investigation scope for:
- How 5G Media Streaming requirements align with SCONE-PRO/SCONE objectives
- Potential combination scenarios between SCONE and 5G Media Streaming
- Required extensions to 5G Media Streaming for SCONE integration

## Impact Assessment

**Benefits:**
- Comprehensive documentation of IETF SCONE protocol evolution
- Clear technical specification for 3GPP-IETF coordination
- Foundation for potential normative work in 5G Media Streaming specifications
- Addresses operator traffic management challenges while improving user QoE

**Coordination Requirements:**
- Ongoing liaison with IETF SCONE WG
- Potential impacts on SA2 (architecture), SA3 (security), SA5 (management)
- External coordination with SVTA, CTA WAVE, ISO/IEC JTC29 WG3, 5G-MAG, DVB