Draft: draft-ietf-mops-streaming-opcons

Commentary: please let me know if this is the kind of thing you were asking for . Thanks ! 
 It 's a very good step in the right direction . Basically very close to resolved . I 've made specific comments / suggestion in the PR . 
 I merged this PR based on comments above with so that we 'll have it in the next draft we submit . 
 the current draft mentions that TCP has a feedback control mechanism while UDP does n't etc . It also mentions ABR but with out much detail on what exactly is going on with ABR . It may be helpful to the reader to have a section that goes a little bit into the mechanism that are being used at the application level . while application behavior is often outside of the interest by IETF documents , in this case the application 's are making choices and collecting data that are directly connected to network performance , and in turn make changes to the applications use of the network and consequently the video transports impact to the network . There are a couple mechanisms by video applications which could be viewed as essentially seen as application layer network management . 1 . ABR - which is lightly mentioned in the current draft , 2 . Adaptive encoding , 3 . player and edge data collection , coupled with a feedback mechanism to the video server and even the player that cause adaptive change decisions on the data being sent such as systems like  . Not suggesting a huge section , but something should be included about how application layer monitoring and adaptive decision making by players / servers is a form of network flow / use flow control especially when UDP / QUIC transport is used , but certainly it 's impactful for TCP flows . 
  , I think I can also cover this in ( which is still moving rapidly , so do n't peek at it for a couple of days ) . And I really like these observations . I know this topic matters , and I 'll do my best to reflect your issue . 
 after looking at this a bit more , I think most of the work is in what is now called the ABR section , which I have n't touched in . I 'm going to unlink that PR , and start working on a new one . Please stay tuned . 
 Just to follow up here - I think the ABR section is a good start for suggested three - part section , which I 'm now seeing as four sections - the fourth , describing the challenges that application - level mechanisms have to anticipate in adapting media streams . I 'm planning to use the existing subsections on Idle Time Between Segments , Head - of - Line Blocking , and Unreliable Transports in that fourth section . So , as said - not a huge section ( because where would we stop ? ) , but some additional words that provide context for adaptive streaming .
Paragraph (version A):
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 A):
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.
Paragraph (version A):
This kind of bandwidth-measurement systems can experience trouble in
several ways that can be affected by networking design choices.
Paragraph (version B):
Media servers can provide media streams at various bitrates because
the media has been encoded at various bitrates.  This is a so-called
"ladder" of bitrates, that can be offered to media players as part of
the manifest that describes the media being requested by the media
player, so that the media player can select among the available
bitrate choices.
Paragraph (version B):
The media server may also choose to alter which bitrates are made
available to players by adding or removing bitrate options from the
ladder delivered to the player in subsequent manifests built and sent
to the player.
Paragraph (version B):
In this way both the player, through its selection of bitrate to
request from the manifest, and the server, through its construction
of the bitrates offered in the manifest, are able to affect network
utilization.
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 relying on proprietary algorithms (called rate
adaptation or bitrate selection algorithms) to perform available
bandwidth estimation/prediction and the bitrate selection.
Paragraph (version B):
Many server-player systems will do an initial probe or a very simple
throughput speed test at the start of a video playback.  This is done
to get a rough sense of the highest video bit rate 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 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 event (playback stall).
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,
ase 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.  Conviva is an example of one such such
measurement collection system in use today.