Draft: draft-ietf-mops-streaming-opcons

Commentary:  , this PR looks nice . Two meta - issues ( which we can talk about whenever ) . I changed my references in the draft to a more complete format ( using ins : can result in odd formatting in the References section ) . We do n't have to do that for all the references in -04 , but that would be a good thing to do in an editorial pass . I see that you 're making some terminology changes ( from " delivery " to " streaming " , stuff like that ) . I agree with the changes you made in this PR , but we may want to make sure that they are made globally , for consistency . 
 I was not sure about the reference format , normally I just use the casual format : Authors , " Title , " Journal / Conference , Date . I saw the missing author names and realized " ins " would do the trick . By no means , I am tied to that format - do n't know even know what " ins " stands for here :) 
 From : " as in the author list , ins is an abbreviation for " initials / surname " ; " I tend to think an editorial pass on references would be better as a separate commit , where they need cleaning . Anything that somehow made it in and breaks the " make " needs fixing , but others maybe later ? 
 I suggest a definition along these lines : Streaming is transmission of a continuous content from a server to a client and its simultaneous consumption by the client . ( " simultaneous " is the key here ) This has two implications : 1 ) Server transmission rate ( loosely or tightly ) matches to client consumption rate . That is , no buffer overrun or underrun is desirable / acceptable . 2 ) Client consumption rate is also limited by real - time constraints as opposed to just bandwidth availability . That is , client can not fetch the content not available yet . 
 +1 , this sgtm . But this probably implies a refactor of the intro section and the abstract , to better focus on the relevant use case . 
 I can take a crack at this . 
  has text for this , will create a PR for the issue .
Paragraph (version A):
This document provides an overview of operational networking issues
that pertain to quality of experience in delivery of video and other
high-bitrate media over the internet.
Paragraph (version B):
This document provides an overview of operational networking issues
that pertain to quality of experience in streaming of video and other
high-bitrate media over the internet.
Paragraph (version B):
A substantial part of this growth is due to increased use of
streaming video, although the amount of video traffic in real-time
communications (for example, online videoconferencing) has also grown
significantly.  While both streaming video and videoconferencing have
real-time delivery and latency requirements, these requirements vary
from one application to another.  For example, videoconferencing
demands an end-to-end (one-way) latency of a few hundreds of
milliseconds whereas live streaming can tolerate latencies of several
seconds.
Paragraph (version B):
This document specifically focuses on the streaming applications and
defines streaming as follows: Streaming is transmission of a
continuous media from a server to a client and its simultaneous
consumption by the client.  Here, continous media refers to media and
associated streams such as video, audio, metadata, etc.  In this
definition, the critical term is "simultaneous", as it is not
considered streaming if one downloads a video file and plays it after
the download is completed, which would be called download-and-play.
This has two implications.  First, server's transmission rate must
(loosely or tightly) match to client's consumption rate for an
uninterrupted playback.  That is, the client must not run out of data
(buffer underrun) or take more than it can keep (buffer overrun) as
any excess media is simply discarded.  Second, client's consumption
rate is limited by not only bandwidth availability but also the real-
time constraints.  That is, the client cannot fetch media that is not
available yet.
Paragraph (version A):
In more immersive applications, where basic user movement (3DoF+) or
full user movement (6DoF) is allowed, the required bitrate grows even
further.  In this case, the immersive content is typically referred
to as volumetric media.  One way to represent the volumetric media is
to use point clouds, where streaming a single object may easily
require a bitrate of 30 Mbps or higher.  Refer to PCC for more
details.
Paragraph (version B):
In more immersive applications, where basic user movement (3DoF+) or
full user movement (6DoF) is allowed, the required bitrate grows even
further.  In this case, the immersive content is typically referred
to as volumetric media.  One way to represent the volumetric media is
to use point clouds, where streaming a single object may easily
require a bitrate of 30 Mbps or higher.  Refer to MPEGI and PCC for
more details.
Paragraph (version A):
Adaptive BitRate (ABR) is a sort of application-level response
strategy in which the receiving media player attempts to detect the
available bandwidth of the network path by experiment or by observing
the successful application-layer download speed, then chooses a video
bitrate (among the limited number of available options) that fits
within that bandwidth, typically adjusting as changes in available
bandwidth occur in the network or changes in capabilities occur in
the player (such as available memory, CPU, display size, etc.).
Paragraph (version A):
The choice of bitrate occurs within the context of optimizing for
some metric monitored by the video player, such as highest achievable
video quality, or lowest rate of expected rebuffering events.
Paragraph (version A):
ABR playback is commonly implemented by video players using HLS
RFC8216 or DASH DASH to perform a reliable segmented delivery of
video data over HTTP.  Different player implementations and receiving
devices use different strategies, often proprietary algorithms
(called rate adaptation or bitrate selection algorithms), to perform
available bandwidth estimation/prediction and the bitrate selection.
Most players only use passive observations, i.e., they do not
generate probe traffic to measure the available bandwidth.
Paragraph (version B):
Adaptive BitRate (ABR) is a sort of application-level response
strategy in which the streaming client attempts to detect the
available bandwidth of the network path by observing the successful
application-layer download speed, then chooses a bitrate for each of
the video, audio, subtitles and metadata (among the limited number of
available options) that fits within that bandwidth, typically
adjusting as changes in available bandwidth occur in the network or
changes in capabilities occur during the playback (such as available
memory, CPU, display size, etc.).
Paragraph (version B):
The choice of bitrate occurs within the context of optimizing for
some metric monitored by the client, such as highest achievable video
quality or lowest chances for a rebuffering (playback stall).
Paragraph (version B):
ABR playback is commonly implemented by streaming clients using HLS
RFC8216 or DASH DASH to perform a reliable segmented delivery of
media over HTTP.  Different implementations use different strategies
ABRSurvey, often proprietary algorithms (called rate adaptation or
bitrate selection algorithms) to perform available bandwidth
estimation/prediction and the bitrate selection.  Most clients only
use passive observations, i.e., they do not generate probe traffic to
measure the available bandwidth.