Use Cases document
Closed this issue · 7 comments
Mostly a placeholder to call out that we should work on a use cases document to help shape/guide the metrics we will need and identify relevant actors (player to server, server to origin, etc.)
** CMSD Use Cases - Player and CDN
-
Providing player with source of error
For any 4xx, 5xx received by player, it is helpful to know the source of this error code such that player can take appropriate action, such as, either switch CDN or switch bitrate. -
Providing player with latency info
To assess the source of highest latency and have a view of latency breakdown, it is helpful to know if the latency is between player <-> CDN, CDN <-> Mid-tier, Mid-Tier <-> Origin.
This info can be used by player to switch CDNs or bitrates. -
Source of Response Bytes (cache-hit/miss/etc.)
Discussion at 6/7 meeting - consensus around adding an informative appendix to the spec documenting the use-cases.
etp/mb/Transport-info metrics can be useful for:
- Assist or drive the media quality selection algorithms for streaming media.
- Inform initial rate selection.
- Provide better bandwidth information for shorter requests (e.g. gRPC, audio) which are harder to measure [at the client]
- The RTT values are useful for informing the operation of latency sensitive applications.
- The RTTVAR could be used to provide an estimate of 'reliability' of rtt and bandwidth estimates.
- Inform client/browser media/data caching strategies.
- Use by intermediate nodes for traffic analytics and control.
Some potential use cases angles been thinking about:
Auto slating on errors, if network can’t keep up with a live feed upstream it might compensate with temporary slate segments or bit stuffing a lower quality stream at same profile and later self recover rather than say stop the stream
Censored/profanity filtering - you might have reason to have proxy nodes physically in a certain geolocation, that location might have reason to restrict parts of the content
Dynamic pricing - multiple CDNs could spot price against each other over the duration of an event depending on actual demand vs revenue target for a local edge demographic
Piracy fingerprinting, identifying a pirate streamer by deductions from contents of CMSD metadata vs known video, audio variants provided by each edge node at a given time
Supply and demand - player can choose quality based on a budget - one CDN path might be cheaper than another (note that ‘cheapest’ option isn’t necessarily what consumers are asking for) CMSD adjusts to demand or possibly selects r outs that injects more or removes ads or lowers or increases quality/resolution offerings
Auto slating on errors, if network can’t keep up with a live feed upstream it might compensate with temporary slate segments or bit stuffing a lower quality stream at same profile and later self recover rather than say stop the stream
The new DASH edition has this concept of slate segments (if the packager has loss on the input, it can generate them instead). Is this something we should expect the CDN servers to do? I doubt it. Also stuffing bits from the lower quality bitstream means that the server actually knows a lot of things about the segments (pretty much all the stuff in the MPD).
Censored/profanity filtering - you might have reason to have proxy nodes physically in a certain geolocation, that location might have reason to restrict parts of the content
How do you suggest the server knows about these parts?
Piracy fingerprinting, identifying a pirate streamer by deductions from contents of CMSD metadata vs known video, audio variants provided by each edge node at a given time
CMSD is optional to implement and to use. How can it be used for fingerprinting?
Uses cases proposed by M. Lim, M. Akcay, A. Bentaleb, A. Begen, R. Zimmermann.
- A client that would mistakenly downshift due to misinterpretation of a cache miss can be warned via CMSD. Another client that would normally start the session with the lowest-bitrate segments can be hinted to fetch higher-bitrate segments.
- Oscillating clients can be assisted and easily stabilized via CMSD.
- Caching storage capacity is limited in practice. Thus, not all encodings can be cached on every server and rate-adapting clients can get confused in certain circumstances. CMSD also helps in this case using caching indications to list what is cached or not cached letting the clients make more informed decisions.
- CMSD can let the clients know the latest (live-edge) segment in low-latency live streaming.
- CMSD can assist in synchronized viewing among the clients at distinct places.
Closing this tracking issue as the use cases were formalized in the v1 candidate recommendation. These are listed below:
Annex B. Informative Use-Case Definitions (Informative)
- Identifying intermediaries in the media distribution chain, for the purposes of investigating delivery and resolving availability issues.
- Provide an estimate of the throughput available between an edge server and a player, such that the player can use that information to enrich its decision about which bitrate to select, especially the initial bitrate decision made at the start of playback.
- Provide link and server characteristics to a client for the purposes of the client making load balancing decisions between multiple potential servers.
- Provide a means for a CDN to instruct all connected players to limit their upper bitrate, in response to an ISP request to reduce congestion on the last-mile network.
- Provide information which an intermediary could use to prefetch the next item in a sequence of media objects. Prefetching increases performance by moving the object closer to the player ahead of the player’s request for that object.
- Provide information about the media characteristics of a binary object, for forensic, logging, or delivery optimization purposes.
- Allow an intermediary to prefetch init segments ahead of a player request.
- Identify media segments located at the start of playback when delivery performance is most critical due to the player’s need to establish a buffer. By identifying these segments, intermediaries can take special measures to optimize their delivery performance.
- Allow for an extensibility mechanism for CMSD so that future upgrades can be made and clients and servers can both agree on the generation and interpretation of the keys and values.
- Allow a CDN to signal to a player a suggested playback bitrate in order to optimize collective QoE.
- Allow a CDN edge server to prefetch a range of a track file that will be guaranteed to include the next media segment range requested by the client.
- Provide information about the timing of media segments to assist players with low latency live streaming.