Draft: draft-ietf-mops-streaming-opcons

Commentary: I did review this before merging it . Thank you , for the PR . 
 and please let me know what you think . I think this document is primarily about video streaming - guidance about the is n't present in this document . We 're using both terms in the document , sometimes in the same section . If there are meaningful differences , I ca n't find them in the document . Should we ( roughly ) s / media / video / g ? 
 After an editor huddle , we actually ARE talking about more media types than just video , but the major operational considerations we have experience with are mostly pointed toward video . What we might do , that 's not a global replacement , is assume that the document IS about media in general , and make sure that when we do mention video , that 's intentional . But we should talk about this before we pull the trigger . 
 I am biased toward keeping " media " while acknowledging that most of the discussion relates to video . We should use " media " everywhere except where we specifically talk about " video " ( for example , if we are talking about resolution , frame rate but not bitrate ) . Video plays a bigger role in this because of its higher requirements than say audio or timed text . 
 From - 
 Well , " a few users " should not be read literally in this context . Surely , there can be many users when serving a latency under a second , but the scale is orders of magnitude different than other live streaming scenarios ( 10 - 100s vs. millions ) . Maybe we can revise the text as follows : s / 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 . /Worth noting is that many applications for ultra - low - latency delivery do not need to scale to as many users as the low - latency and non - low - latency live delivery , which simplifies many delivery considerations relative to other use cases .
Paragraph (version A):
General guidance on bandwidth provisioning (bwprov) and latency
considerations (latency-cons) for streaming video delivery,
Paragraph (version B):
General guidance on bandwidth provisioning (bwprov) and latency
considerations (latency-cons) for streaming media delivery,
Paragraph (version A):
A description of existing transport protocols used for video
streaming and the issues encountered when using those protocols,
along with a description of the QUIC transport protocol RFC9000
more recently used for streaming media (sec-trans),
Paragraph (version B):
A description of existing transport protocols used for media
streaming and the issues encountered when using those protocols,
along with a description of the QUIC transport protocol RFC9000
more recently used for streaming media (sec-trans),
Paragraph (version A):
in-depth examination of real-time two-way interactive media, such
as video conferencing; although this document touches lightly on
topics related to this space, the intent is to let readers know
that for more in-depth coverage, they should look to other
documents, since the techniques and issues for interactive real-
time two-way media differ so dramatically from those in large-
scale one-way delivery of streaming media.
Paragraph (version B):
in-depth examination of real-time two-way interactive media, such
as videoconferencing; although this document touches lightly on
topics related to this space, the intent is to let readers know
that for more in-depth coverage, they should look to other
documents, since the techniques and issues for interactive real-
time two-way media differ so dramatically from those in large-
scale one-way delivery of streaming media.
Paragraph (version A):
In many contexts, video traffic can be handled transparently as
generic application-level traffic.  However, as the volume of video
traffic continues to grow, it is becoming increasingly important to
consider the effects of network design decisions on application-level
performance, with considerations for the impact on video delivery.
Paragraph (version B):
In many contexts, media traffic can be handled transparently as
generic application-level traffic.  However, as the volume of media
traffic continues to grow, it is becoming increasingly important to
consider the effects of network design decisions on application-level
performance, with considerations for the impact on media delivery.
Paragraph (version A):
Even when the bandwidth requirements for video streams along a path
are well understood, additional analysis is required to understand
the constraints on bandwidth at various points along the path between
media servers and media players.  Video streams can encounter
bottlenecks at many points along a path, whether the bottleneck
happens at a node or at a path segment along the path, and these
bottlenecks may involve a lack of processing power, buffering
capacity, link speed, or any other exhaustible resource.
Paragraph (version B):
Even when the bandwidth requirements for media streams along a path
are well understood, additional analysis is required to understand
the constraints on bandwidth at various points along the path between
media servers and media players.  Media streams can encounter
bottlenecks at many points along a path, whether the bottleneck
happens at a node or at a path segment along the path, and these
bottlenecks may involve a lack of processing power, buffering
capacity, link speed, or any other exhaustible resource.
Paragraph (version A):
rendering the stream often had the video freeze until the player was
reset.  In some cases, the truncated object was even cached that way
and served later to other players as well, causing continued stalls
at the same spot in the video for all players playing the segment
delivered from that cache node.
Paragraph (version B):
rendering the stream often had a playback freeze until the player was
reset.  In some cases, the truncated object was even cached that way
and served later to other players as well, causing continued stalls
at the same spot in the media for all players playing the segment
delivered from that cache node.
Paragraph (version A):
Many access networks for end users used underlying technologies
that are inherently asymmetric, favoring downstream bandwidth
(e.g., ADSL, cellular technologies, most IEEE 802.11 variants),
assuming that most users will need more downstream bandwidth than
upstream bandwidth.  This is a good assumption for client-server
applications such as streaming video or software downloads, but
BitTorrent rewarded peers that uploaded as much as they
downloaded, so BitTorrent users had much more symmetric usage
profiles, which interacted badly with these asymetric access
network technologies.
Paragraph (version B):
Many access networks for end users used underlying technologies
that are inherently asymmetric, favoring downstream bandwidth
(e.g., ADSL, cellular technologies, most IEEE 802.11 variants),
assuming that most users will need more downstream bandwidth than
upstream bandwidth.  This is a good assumption for client-server
applications such as streaming media or software downloads, but
BitTorrent rewarded peers that uploaded as much as they
downloaded, so BitTorrent users had much more symmetric usage
profiles, which interacted badly with these asymetric access
network technologies.
Paragraph (version A):
Early in 2020, the COVID-19 pandemic and resulting quarantines and
shutdowns led to significant changes in traffic patterns due to a
large number of people who suddenly started working and attending
school remotely and using more interactive applications (video
conferencing, in addition to streaming media).  Subsequently, the
Internet Architecture Board (IAB) held a COVID-19 Network Impacts
Workshop RFC9075 in November 2020.  The following observations from
the workshop report are worth considering.
Paragraph (version B):
Early in 2020, the COVID-19 pandemic and resulting quarantines and
shutdowns led to significant changes in traffic patterns due to a
large number of people who suddenly started working and attending
school remotely and using more interactive applications
(videoconferencing, in addition to streaming media).  Subsequently,
the Internet Architecture Board (IAB) held a COVID-19 Network Impacts
Workshop RFC9075 in November 2020.  The following observations from
the workshop report are worth considering.
Paragraph (version A):
The usage pattern changed significantly as work-from-home and
videoconferencing usage peaked during normal work hours, which
would have typically been off-peak hours with adults at work and
children at school.  One might expect that the peak would have had
more impact on networks if it had happened during typical evening
peak hours for video streaming applications.
Paragraph (version B):
The usage pattern changed significantly as work-from-home and
videoconferencing usage peaked during normal work hours, which
would have typically been off-peak hours with adults at work and
children at school.  One might expect that the peak would have had
more impact on networks if it had happened during typical evening
peak hours for streaming applications.
Paragraph (version A):
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 the 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 media encoding/decoding and
buffering time, and for most cases also the ingest to an intermediate
service such as a CDN or other media distribution service, rather
than a direct connection to an end user.
Paragraph (version A):
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):
Worth noting is that many applications for ultra-low-latency delivery
do not need to scale to as many users as the low-latency and non-low-
latency live delivery, which simplifies many delivery considerations
relative to other use cases.
Paragraph (version A):
Applications requiring low-latency live media delivery are generally
feasible at scale with some restrictions.  This typically requires
the use of a premium service dedicated to the delivery of live video,
and some tradeoffs may be necessary relative to what is feasible in a
higher latency service.  The tradeoffs may include higher costs,
delivering a lower quality video, reduced flexibility for adaptive
bitrates or reduced flexibility for available resolutions so that
fewer devices can receive an encoding tuned for their display.  Low-
latency live delivery is also more susceptible to user-visible
disruptions due to transient network conditions than higher latency
services.
Paragraph (version B):
Applications requiring low-latency live media delivery are generally
feasible at scale with some restrictions.  This typically requires
the use of a premium service dedicated to the delivery of live media,
and some tradeoffs may be necessary relative to what is feasible in a
higher latency service.  The tradeoffs may include higher costs,
delivering a lower quality media, reduced flexibility for adaptive
bitrates or reduced flexibility for available resolutions so that
fewer devices can receive an encoding tuned for their display.  Low-
latency live delivery is also more susceptible to user-visible
disruptions due to transient network conditions than higher latency
services.
Paragraph (version A):
This level of latency is the historically common case for segmented
video delivery using HLS and DASH.  This level of latency is often
considered adequate for content like news or pre-recorded content.
This level of latency is also sometimes achieved as a fallback state
when some part of the delivery system or the client-side players do
not have the necessary support for the features necessary to support
low-latency live streaming.
Paragraph (version B):
This level of latency is the historically common case for segmented
media delivery using HLS and DASH.  This level of latency is often
considered adequate for content like news or pre-recorded content.
This level of latency is also sometimes achieved as a fallback state
when some part of the delivery system or the client-side players do
not have the necessary support for the features necessary to support
low-latency live streaming.
Paragraph (version A):
On-demand media generally is not subject to latency concerns, but
other timing-related considerations can still be as important or even
more important to the user experience than the same considerations
with live events.  These considerations include the startup time, the
stability of the media stream's playback quality, and avoidance of
stalls and video artifacts during the playback under all but the most
severe network conditions.
Paragraph (version A):
In some applications, optimizations are available to on-demand video
that are not always available to live events, such as pre-loading the
first segment for a startup time that doesn't have to wait for a
network download to begin.
Paragraph (version B):
On-demand media generally is not subject to latency concerns, but
other timing-related considerations can still be as important or even
more important to the user experience than the same considerations
with live events.  These considerations include the startup time, the
stability of the media stream's playback quality, and avoidance of
stalls and other media artifacts during the playback under all but
the most severe network conditions.
Paragraph (version B):
In some applications, optimizations are available to on-demand media
that are not always available to live events, such as pre-loading the
first segment for a startup time that does not have to wait for a
network download to begin.
Paragraph (version A):
A simple model of video playback can be described as a video stream
consumer, a buffer, and a transport mechanism that fills the buffer.
The consumption rate is fairly static and is represented by the
content bitrate.  The size of the buffer is also commonly a fixed
size.  The buffer fill process needs to be at least fast enough to
ensure that the buffer is never empty, however, it also can have
significant complexity when things like personalization or
advertising insertion workflows are introduced.
Paragraph (version B):
A simple model of media playback can be described as a media stream
consumer, a buffer, and a transport mechanism that fills the buffer.
The consumption rate is fairly static and is represented by the
content bitrate.  The size of the buffer is also commonly a fixed
size.  The buffer fill process needs to be at least fast enough to
ensure that the buffer is never empty, however, it also can have
significant complexity when things like personalization or
advertising insertion workflows are introduced.
Paragraph (version A):
Adaptive bitrate streaming ("ABR streaming", or simply "ABR") is a
commonly used technique for dynamically adjusting the compression
level and video quality of a stream to match bandwidth availability.
When this goal is achieved, the media server will tend to send enough
media that the media player does not "stall", without sending so much
media that the media player cannot accept it without exhausting all
available receive buffers.
Paragraph (version B):
Adaptive bitrate streaming ("ABR streaming", or simply "ABR") is a
commonly used technique for dynamically adjusting the compression
level and media quality of a stream to match bandwidth availability.
When this goal is achieved, the media server will tend to send enough
media that the media player does not "stall", without sending so much
media that the media player cannot accept it without exhausting all
available receive buffers.
Paragraph (version A):
Many systems will do an initial probe or a very simple throughput
speed test at the start of video playback.  This is done to get a
rough sense of the highest video bitrate in the ABR ladder that the
network between the server and player will likely be able to provide
under initial network conditions.  After the initial testing, clients
tend to rely upon passive network observations and will make use of
player side statistics such as buffer fill rates to monitor and
respond to changing network conditions.
Paragraph (version A):
The choice of bitrate occurs within the context of optimizing for one
or more metrics monitored by the client, such as the highest
achievable video quality or lowest chances for a rebuffering event
(playback stall).
Paragraph (version B):
Many systems will do an initial probe or a very simple throughput
speed test at the start of media playback.  This is done to get a
rough sense of the highest (total) media bitrate that the network
between the server and player will likely be able to provide under
initial network conditions.  After the initial testing, clients tend
to rely upon passive network observations and will make use of player
side statistics such as buffer fill rates to monitor and respond to
changing network conditions.
Paragraph (version B):
The choice of bitrate occurs within the context of optimizing for one
or more metrics monitored by the client, such as the highest
achievable audiovisual quality or lowest chances for a rebuffering
event (playback stall).
Paragraph (version A):
In general, the more targeted the ad request is, the more requests
the ad service needs to be able to handle concurrently.  If
connectivity is poor to the ad service, this can cause rebuffering
even if the underlying video assets (both content and ads) can be
accessed quickly.  The less targeted the ad request is, the more
likely that ad requests can be consolidated, and that ads can be
cached similarly to the video content.
Paragraph (version A):
In some cases, especially with SSAI, advertising space in a stream is
reserved for a specific advertiser and can be integrated with the
video so that the segments share the same encoding properties such as
bitrate, dynamic range, and resolution.  However, in many cases, ad
servers integrate with a Supply Side Platform (SSP) that offers
advertising space in real-time auctions via an Ad Exchange, with bids
for the advertising space coming from Demand Side Platforms (DSPs)
that collect money from advertisers for delivering the
advertisements.  Most such Ad Exchanges use application-level
protocol specifications published by the Interactive Advertising
Bureau IAB-ADS, an industry trade organization.
Paragraph (version B):
In general, the more targeted the ad request is, the more requests
the ad service needs to be able to handle concurrently.  If
connectivity is poor to the ad service, this can cause rebuffering
even if the underlying media assets (both content and ads) can be
accessed quickly.  The less targeted the ad request is, the more
likely that ad requests can be consolidated, and that ads can be
cached similarly to the media content.
Paragraph (version B):
In some cases, especially with SSAI, advertising space in a stream is
reserved for a specific advertiser and can be integrated with the
video so that the segments share the same encoding properties such as
bitrate, dynamic range and resolution.  However, in many cases, ad
servers integrate with a Supply Side Platform (SSP) that offers
advertising space in real-time auctions via an Ad Exchange, with bids
for the advertising space coming from Demand Side Platforms (DSPs)
that collect money from advertisers for delivering the
advertisements.  Most such Ad Exchanges use application-level
protocol specifications published by the Interactive Advertising
Bureau IAB-ADS, an industry trade organization.
Paragraph (version A):
This ecosystem balances several competing objectives and integrating
with it naively can produce surprising user experience results.  For
example, ad server provisioning and/or the bitrate of the ad segments
might be different from that of the main video, and either of these
differences can result in video stalls.  For another example, since
the inserted ads are often produced independently, they might have a
different base volume level than the main video, which can make for a
jarring user experience.
Paragraph (version B):
This ecosystem balances several competing objectives and integrating
with it naively can produce surprising user experience results.  For
example, ad server provisioning and/or the bitrate of the ad segments
might be different from that of the main content, and either of these
differences can result in playback stalls.  For another example,
since the inserted ads are often produced independently, they might
have a different base volume level than the main content, which can
make for a jarring user experience.
Paragraph (version A):
raw MPEG Transport Stream ("MPEG-TS")-formatted video MPEG-TS over
UDP, which makes no attempt to account for reordering or loss in
the transport,
Paragraph (version B):
raw MPEG Transport Stream ("MPEG-TS")-formatted media MPEG-TS over
UDP, which makes no attempt to account for reordering or loss in
the transport,
Paragraph (version A):
Under congestion and loss, approaches like the above generally
experience transient video artifacts more often and delay of playback
effects less often, as compared with reliable segment transport.
Often one of the key goals of using a UDP-based transport that allows
some unreliability is to reduce latency and better support
applications like videoconferencing, or for other live-action video
with interactive components, such as some sporting events.
Paragraph (version B):
Under congestion and loss, approaches like the above generally
experience transient media artifacts more often and delay of playback
effects less often, as compared with reliable segment transport.
Often one of the key goals of using a UDP-based transport that allows
some unreliability is to reduce latency and better support
applications like videoconferencing, or for other live-action video
with interactive components, such as some sporting events.