Push Mode Extension for DASH Content Steering (Version 2)

[burak-kara]

Note: The explanations and examples in this issue focus primarily on DASH Content Steering. However, the core idea is equally applicable to HLS Content Steering, potentially requiring minor adjustments for full compatibility. This proposal is intentionally presented in draft mode to foster discussion, refinement, and maturation within the community, which is the primary aim of opening this issue.

Problem Statement

The current Content Steering specification(s) relies entirely on a client-driven, pull-based model.
Today, once a server has sent the DASH Content Steering Manifest (DCSM), it has no means to proactively update the client until the client initiates the next scheduled pull.
Thus, if an event requiring a critical DCSM update occurs shortly after a client’s most recent pull, the server must wait until the subsequent client request to communicate the change.
To mitigate the risk of outdated steering information, servers typically set very short TTL values, causing clients to frequently pull updates.
However, since steering events are relatively infrequent, the overwhelming majority of these frequent pulls return identical or nearly identical data, resulting in inefficient network utilization and unnecessary load.
This inefficiency must be addressed by enabling servers to proactively update steering manifests only when needed.

Objective

The objective of this proposal is to enhance the current content steering mechanism by introducing a hybrid model that combines the existing pull-based approach with a new push-based mode.

This extended approach specifically aims to:

• Minimize latency between steering decisions and their delivery to clients, allowing immediate reaction to network or service events.
• Reduce network load caused by frequent client polling with unchanged data.
• Enable real-time and proactive steering decisions, improving overall streaming performance and QoE.
• Maintain backward compatibility to ensure seamless integration with existing DASH and HLS implementations.

Proposed Solution

The proposed hybrid solution maintains compatibility with existing DASH clients by introducing versioning. It defines a new version (Version 2) of the DCSM, which explicitly supports a push-based delivery mechanism alongside the existing pull-based model.

While this proposal illustrates the push-based mode using Server-Sent Events (SSE) as a practical example, alternative technologies such as WebSockets could also be considered, defined, and implemented. The intention is to open this aspect to community input and identify the most suitable and widely adoptable technology through collaborative discussion.

Manifest Structure

The MPD manifest structure remains fully compatible with the current specification.
No modifications are needed; it continues pointing to the steering server via the existing signaling mechanism.

Initial Client Request

Clients indicate support for the proposed hybrid model by explicitly specifying a version identifier (v=2) during the initial request to the steering server.
Clients that do not specify this version identifier default to the existing Version 1 behavior, supporting only pull-based updates.

Example initial request indicating Version 2 capability:

GET https://steeringservice.com/app/instance1234?session=abc&v=2 HTTP/1.1
Accept: application/dcsm+json;version=2, application/json;q=0.9

DCSM Version 2 Structure

The DCSM Version 2 JSON structure remains largely consistent with Version 1 to facilitate backward compatibility.
The primary enhancement is the extended definition of the RELOAD-URI object, which explicitly separates pull-based and push-based endpoints.

{
    "VERSION": 2, 
    "TTL": 300, // unchanged from Version 1
    "RELOAD-URI": {
        "PULL": "https://steeringservice.com/app/instance1234?v=2", // Endpoint for periodic pull requests
        "PUSH": "https://steeringservice.com/app/instance1234/push" // Endpoint to establish push connection
    },
    "PATHWAY-PRIORITY": ["beta", "alpha"], // unchanged from Version 1
    "PATHWAY-CLONES": [] // unchanged from Version 1
}

Clients supporting Version 2 specifically recognize and process the RELOAD-URI object to determine distinct URIs for handling pull-based updates and establishing push-based connectivity.

Client Behavior

Clients supporting Version 2 follow these enhanced steering behaviors:

• Upon receiving the DCSM Version 2, clients first examine whether the RELOAD-URI object includes a PUSH URI.
• If a PUSH URI is present, clients establish and maintain a Server-Sent Events (SSE) connection (or alternative push channel, depending on the agreed implementation).
• In parallel, clients maintain their traditional pull-based update cycle by setting a periodic timer according to the TTL value provided in the manifest.
• Any incoming push updates from the server are applied immediately upon reception. Additionally, each push update resets the client's internal TTL timer, reducing redundant polling.
• If the push channel remains inactive (i.e., no push messages received) for a predefined duration (for example, X multiples of the current TTL), clients consider the push channel disconnected or unreliable. In this scenario, clients gracefully degrade to exclusively using the pull-based mechanism until the push channel can be successfully re-established.

---

Next Steps

We propose using this GitHub issue as a platform for collaborative brainstorming and discussion to mature this or similar push-mode approaches before potentially proposing them to HLS for integration into standards .
We invite feedback and contributions from the community to refine and expand upon this proposal.