Draft: draft-ietf-mops-streaming-opcons

Commentary: I think we should wait until the [ CTA-5004 ] reference link is resolved to merge this PR . 
 I made this change in the CMCD branch . We can merge it when we 're ready . 
 Will resolve conflicts and merge . 
 We could reasonably start with standardized mechanisms , and could also give other examples . Also provide links to specifications that provide guidance on what to measure . 
 Replace : In addition to measurements media players use to guide their segment - by - segment adaptive streaming requests , streaming media providers may also rely on measurements collected from media players to provide analytics that can be used for decisions such as whether the adaptive encoding bitrates in use are the best ones to provide to media players , or whether current media content caching is providing the best experience for viewers . With : In addition to measurements media players use to guide their segment - by - segment adaptive streaming requests , streaming media providers may also rely on measurements collected from media players to provide analytics that can be used for decisions such as whether the adaptive encoding bitrates in use are the best ones to provide to media players , or whether current media content caching is providing the best experience for viewers . To that effect , the Consumer Technology Association ( CTA ) who owns the Web Application Video Ecosystem ( WAVE ) project has published two important specifications . CTA-2066 specifies a set of media player events , properties , quality of experience ( QoE ) metrics and associated terminology for representing streaming media quality of experience across systems , media players and analytics vendors . While all these events , properties , metrics and associated terminology is used across a number of proprietary analytics and measurement solutions , they were used in slightly ( or vastly ) different ways that led to interoperability issues . CTA-2066 attempts to address this issue by defining a common terminology as well as how each metric should be computed for consistent reporting . Many assumes that the CDNs have a holistic view into the health and performance of the streaming clients . However , this is not the case . The CDNs produce millions of log lines per second across hundreds of thousands of clients and they have no concept of a " session " as a client would have , so CDNs are decoupled from the metrics the clients generate and report . A CDN can not tell which request belongs to which playback session , the duration of any media object , the bitrate , or whether any of the clients have stalled and are rebuffering or are about to stall and will rebuffer . The consequence of this decoupling is that a CDN can not prioritize delivery for when the client needs it most , prefetch content , or trigger alerts when the network itself may be underperforming . One approach to couple the CDN to the playback sessions is for the clients to communicate standardized media - relevant information to the CDNs while they are fetching data . CTA-5004 was developed exactly for this purpose . 
 CTA-2066 : CTA-5004 : 
 This should be addressed by .  , please confirm this , and let me know when we can change the reference URL for [ CTA-5004 ] . 
 URL is fixed now , so please use 
 Looks good , and I asked CTA to fix the link and they did , so please use instead :
Paragraph (version A):
Streaming media latency refers to the "glass-to-glass" time duration,
which is the delay between the real-life occurence of an event and
the streamed media being appropriately displayed on an end user's
device.  Note that this is different from the network latency
(defined as the time for a packet to cross a network from one end to
another end) because it includes video encoding/decoding and
buffering time, and for most cases also ingest to an intermediate
service such as a CDN or other video distribution service, rather
than a direct connection to an end user.
Paragraph (version B):
Streaming media latency refers to the "glass-to-glass" time duration,
which is the delay between the real-life occurrence of an event and
the streamed media being appropriately displayed on an end user's
device.  Note that this is different from the network latency
(defined as the time for a packet to cross a network from one end to
another end) because it includes video encoding/decoding and
buffering time, and for most cases also ingest to an intermediate
service such as a CDN or other video distribution service, rather
than a direct connection to an end user.
Paragraph (version A):
This kind of bandwidth-measurement system can experience trouble in
several ways that can be affected by networking design choices.
Because adaptive application-level response strategies are typically
using application-level protocols, these mechanisms are affected by
transport-level protocol behaviors, and the application-level
feedback loop is interacting with a transport-level feedback loop,
ase described in idle-time and hol-blocking.
Paragraph (version B):
This kind of bandwidth-measurement system can experience trouble in
several ways that can be affected by networking design choices.
Because adaptive application-level response strategies are typically
using application-level protocols, these mechanisms are affected by
transport-level protocol behaviors, and the application-level
feedback loop is interacting with a transport-level feedback loop, as
described in idle-time and hol-blocking.
Paragraph (version B):
In addition to measurements media players use to guide their segment-
by-segment adaptive streaming requests, streaming media providers may
also rely on measurements collected from media players to provide
analytics that can be used for decisions such as whether the adaptive
encoding bitrates in use are the best ones to provide to media
players, or whether current media content caching is providing the
best experience for viewers.  To that effect, the Consumer Technology
Association (CTA) who owns the Web Application Video Ecosystem (WAVE)
project has published two important specifications.
Paragraph (version B):
CTA-2066 specifies a set of media player events, properties, quality
of experience (QoE) metrics and associated terminology for
representing streaming media quality of experience across systems,
media players and analytics vendors.  While all these events,
properties, metrics and associated terminology is used across a
number of proprietary analytics and measurement solutions, they were
used in slightly (or vastly) different ways that led to
interoperability issues.  CTA-2066 attempts to address this issue by
defining a common terminology as well as how each metric should be
computed for consistent reporting.
Paragraph (version B):
Many assumes that the CDNs have a holistic view into the health and
performance of the streaming clients.  However, this is not the case.
The CDNs produce millions of log lines per second across hundreds of
thousands of clients and they have no concept of a "session" as a
client would have, so CDNs are decoupled from the metrics the clients
generate and report.  A CDN cannot tell which request belongs to
which playback session, the duration of any media object, the
bitrate, or whether any of the clients have stalled and are
rebuffering or are about to stall and will rebuffer.  The consequence
of this decoupling is that a CDN cannot prioritize delivery for when
the client needs it most, prefetch content, or trigger alerts when
the network itself may be underperforming.  One approach to couple
the CDN to the playback sessions is for the clients to communicate
standardized media-relevant information to the CDNs while they are
fetching data.  CTA-5004 was developed exactly for this purpose.