Draft: draft-ietf-mops-streaming-opcons

Commentary: Yes , lets add it . Well , I really do n't want to imply that right provisioning requires  or at least some DSCP marking . Yes , to many , the answer could be just providing enough bandwidth for others , it could be a bit more complicated . If you have seen my recent ANRW talk , I refer to the " QoS " as the first camp ( slide 5 ) and many efforts to date simply failed in that aspect . Paper : Slides : 
 I like this text . I have thoughts . Do we need a reference for " bufferbloat " ? We have n't used that term in the document yet , and I agree with using it here . I note . I agree with " the right provisioning " , but for someone not skilled in the art , that may be like " and then a miracle occurs " , and I suspect a lot of people still assume " the right provisioning " means something like " the right bandwidth provisioning " , which is n't what we mean at all , is it ? ISTM that we might ( 1 ) mention DSCP , ( 2 ) mention as something to be aware of .
Paragraph (version A):
This level of latency is sometimes necessary for real-time
interactive applications such as video conferencing, operation of
remote control devices or vehicles, or remotely hosted real-time
gaming systems.  Some media content providers aim to achieve this
level of latency for live media events involving sports, but have
usually so far been unsuccessful over the internet at scale, though
it is often possible within a localized environment with a controlled
network, such as inside a specific venue connected to the event.
Applications operating in this domain that encounter transient
network events such as loss or reordering of some packets often
experience user-visible artifacts in the media.
Paragraph (version B):
Some media content providers aim to achieve this level of latency for
live media events.  This introduces new challenges relative to less-
restricted levels of latency requirements because this latency is the
same scale as commonly observed end-to-end network latency variation
(for example, due to effects such as bufferbloat, Wi-Fi error
correction, or packet reordering).  These effects can make it
difficult to achieve this level of latency for the general case, and
may require tradeoffs in relatively frequent user-visible media
artifacts.  However, for controlled environments or targeted networks
that provide mitigations against such effects, this level of latency
is potentially achievable with the right provisioning.
Paragraph (version A):
Worth noting is that many applications for ultra low-latency delivery
do not need to scale to more than one user at a time, which
simplifies many delivery considerations relative to other use cases.
For applications that need to replicate streams to multiple users,
especially at a scale exceeding tens of users, this level of latency
has historically been nearly impossible to achieve except with the
use of multicast or planned provisioning in controlled networks.
Paragraph (version B):
Worth noting is that many applications for ultra low-latency delivery
do not need to scale to more than a few users at a time, which
simplifies many delivery considerations relative to other use cases.
Paragraph (version B):
The following papers describe how video is encoded, different video
encoding standards and tradeoffs in selecting encoding parameters.
Paragraph (version B):
The following papers summarize the methods for selecting packaging
configurations such as the resolution-bitrate pairs, segment
durations, use of constant vs. variable-duration segments, etc.
Paragraph (version B):
The following links describe some of the issues and solutions
regarding the interconnecting of the content delivery networks.
Paragraph (version B):
The two surveys describe and compare different rate-adaptation
algorithms in terms of different metrics like achieved bitrate/
quality, stall rate/duration, bitrate switching frequency, fairness,
network utilization, etc.
Paragraph (version B):
Low-Latency Live Streaming: The following papers describe the
peculiarities of adaptive streaming in low-latency live streaming
scenarios.
Paragraph (version B):
The following papers explain the benefits of server and network
assistance in client-driven streaming systems.  There is also a good
reference about how congestion affects video quality and how rate
control works in streaming applications.
Paragraph (version B):
The following papers describe various QoE metrics one can use in
streaming applications.
Paragraph (version B):
The following papers explain the latest developments in the immersive
media domain (for video and audio) and the developing standards for
such media.
Paragraph (version B):
5G new radio and systems technologies provide new functionalities for
video distribution. 5G targets not only smartphones, but also new
devices such as augmented reality glasses or automotive receivers.
Higher bandwidth, lower latencies, edge and cloud computing
functionalities, service-based architectures, low power consumption,
broadcast/multicast functionalities and other network functions come
hand in hand with new media formats and processing capabilities
promising better and more consistent quality for traditional video
streaming services as well as enabling new experiences such as
immersive media and augmented realities.
Paragraph (version B):
Ads can be inserted at different stages in the streaming workflow, on
the server side or client side.  The DASH-IF guidelines detail
server-side ad-insertion with period replacements based on
manipulating the manifest.  HLS interstitials provide a similar
approach.  The idea is that the manifest can be changed and point to
a sub-playlist of segments, possibly located on a different location.
This approach results in efficient resource usage in the network, as
duplicate caching is avoided, but some intelligence at the player is
needed to deal with content transitions (e.g., codec changes,
timeline gaps, etc.).  Player support for such content is gradually
maturing.  Other important technologies for ad insertion include
signalling of ads and breaks that is still typically based on SCTE-35
for HLS and SCTE-214 for DASH.  Such signals provide useful
information for scheduling the ads and contacting ad servers.  The
usage of SCTE-35 for ad insertion is popular in the broadcast
industry, while the exact usage in the OTT space is still being
discussed in SCTE.  Another important technology is identification of
ads, such as based on ad-id or other commercial entities that provide
such services.  The identification of the ad in a manifest or stream
is usually standardized by SMPTE.  Other key technologies for ad
insertion include tracking of viewer impressions, usually based on
Video Ad Serving Template (VAST) defined by IAB.
Paragraph (version B):
There are different contribution and ingest specifications dealing
with different use cases.  A common case is contribution that
previously happened over satellite to a broadcast or streaming
headend.  RIST and SRT are examples of such contribution protocols.
Within a streaming headend the encoder and packager/CDN may have an
ingest/contribution interface as well.  This is specified by the
DASH-IF Ingest.
Paragraph (version B):
WebRTC is increasingly being used for streaming of time-sensitive
content such as live sporting events.  Innovations in cloud computing
allow implementers to efficiently scale delivery of content using
WebRTC.  Support for WebRTC communication is available on all modern
web browsers and is available on native clients for all major
platforms.