Draft: draft-ietf-mops-streaming-opcons

Commentary: could you let us know if this PR does a better job of describing the scope of the document ? And thank you for your comments ! 
 I am OK with the changes A minor suggestion is to start with streaming media ( not video ) but then it is ok to keep using video . And wrt non - HTTP / ABR streaming approaches , I agree with that there is not really much to report . All those methods with RTP or not ( like RTSP streaming or UDP / RTP multicast IPTV ) required pretty much a solid bandwidth , reserved capacity or some sort of QoS , which we are not really talking about in this document . Sure , RTSP has some rate - control mechanisms ( mostly on the sender side as opposed to the client side , which is not important for this discussion ) , but who does really have some operational data on it ? People started getting concerned about streaming traffic when it got out of the walled gardens ( i.e. , when we started using CDNs and HTTP for video all over the internet ) . 
 I understand the comments from both and I 'll send another commit , and let people check my work . 
 Thank you so much for taking the time to address my comments here . Sorry I 've been delayed in responding . I do think your first pass definitely moves things in the direction of greater clarity . I also agree with that we could use at least some explanation about the relationship between HTTP chunked streaming ( the common case that this document mostly focuses on ) and other forms of media streaming like UDP / RTP . 's comment already contains an important observations that 's probably worth including : namely that streaming media at much lower latencies without a reliable transport protocol typically requires more controlled network conditions to preserve high QoE. I think some language about how HTTP chunked streaming has become predominate specifically due to the cachability of of the delivered objects might be another . If we include language like that about what I 'll loosely generalize as the " UDP / RTP " vs " HTTP chunked streaming " approaches , we could also provide readers with useful context for the types of issues likely to be encountered with WebRTC and/or QUIC as new methods of delivery are explored where the transport protocol may not provide the same reliability guarantees as TCP and more responsibility for mitigating the effects of network conditions on the open Internet may fall to applications . It may be a bit late in this document 's lifecycle to add much content here , but perhaps we can at least hint at future work with how we frame the relationship between the different approaches . Thank you again for considering my feedback and taking the time to make these updates . 
 RTP with RTCP is theoretically supposed to help with the reserved capacity and rmcat is trying to write up approaches that should work ( as experimental and informational so far ) . In theory this should of course work fine , but in terms of operational considerations for streaming over the internet this way , my knowledge is certainly very fuzzy , and from what little I know I somewhat expect that particular operational issues here are off in the weeds of codec - specific encoding and decoding issues around loss and reordering , in a way that abr with reliable segment transfer is not . There might be someone out there who knows more . ( e.g. maybe someone like juberti could write a section like this if we asked nicely and we think it needs including ? ) I think I slightly prefer declaring it out of scope for this doc and coming up with an excuse we can sign onto with a straight face , but I feel a little dirty about that preference , and I 'm not sure it 's quite the same as doing the right thing . 
 Oh , please , let me clean off . The right way forward in my mind is to say something like " this document is mostly about HTTP chunked streaming , because that 's so heavily used . We do mention RTP , but we ca n't give the same quality of guidance for that traffic , and much of what we can say is heavily dependent on the type of codec being used " . Anyone who thinks that we can give that guidance is welcome to send text , of course . Jake , do you still need to be cleaned off more ? 
 I 'd agree that simply qualifying the limitations of the document ( and stating why we think the current focus / scope is a reasonable one ) is the appropriate course to take at this point . Trying to solicit new text from additional contributors who have not already been engaged does n't seem advisable at this stage and I do not have the bandwidth to contribute anything significant right now . Thank you again for your work on these updates . 
 Works for me :) Thanks . 
 THINKS this addresses the last call comments that we 've received on -07 , plus discussion to date about those comments . I 'll submit this as -08 . 
 Thanks for taking a crack at this ,  . It looks like a worthwhile update to me that improves the doc wrt the issue  raised . But I do think this removes the definition of streaming that was a prior suggestion , and on looking it seems like webrtc and rtp - specific operational considerations are notably light . We point at these in a few places but maybe we need a brief explanation of why it 's not in scope or not addressed . ( I think the answer is that there 's not yet a lot of operational experience with using these for media streaming over the internet , as opposed to conferencing or walled - garden deployments ( maybe ? or is this usually raw mpeg udp ? ) , but I 'm not quite sure . ) I guess I 'm thinking to accept this pr , but maybe we should also open a new issue about adding a paragraph to address missing considerations about webrtc or rtp more generally , tho I 'm really not sure . any opinions here ?
Paragraph (version A):
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 A):
Here, continuous 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.
Paragraph (version B):
This document provides an overview of operational networking issues
that pertain to quality of experience when streaming video and other
high-bitrate media over the Internet.
Paragraph (version B):
This document examines networking issues as they relate to quality of
experience in Internet media delivery, especially focusing on
capturing characteristics of streaming video delivery that have
surprised network designers or transport experts who lack specific
video expertise, since streaming media highlights key differences
between common assumptions in existing networking practices and
observations of video delivery issues encountered when streaming
media over those existing networks.
Paragraph (version B):
Here, "continuous 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.
Paragraph (version A):
First, the server's transmission rate must (loosely or tightly)
match to client's consumption rate in order to provide
uninterrupted playback.  That is, the client must not run out of
data (buffer underrun) or accept more data than it can buffer
before playback (buffer overrun) as any excess media is simply
discarded.
Paragraph (version A):
Second, the client's consumption rate is limited not only by
bandwidth availability but also real-time constraints.  That is,
the client cannot fetch media that is not available from a server
yet.
Paragraph (version A):
This document examines networking issues as they relate to quality of
experience in internet video delivery.  The focus is on capturing
characteristics of video delivery that have surprised network
designers or transport experts without specific video expertise,
since these highlight key differences between common assumptions in
existing networking documents and observations of video delivery
issues in practice.
Paragraph (version A):
Making specific recommendations on operational practices aimed at
mitigating these issues is out of scope, though some existing
mitigations are mentioned in passing.  The intent is to provide a
point of reference for future solution proposals to use in describing
how new technologies address or avoid these existing observed
problems.
Paragraph (version B):
First, the server's transmission rate must (loosely or tightly)
match to client's consumption rate in order to provide
uninterrupted playback.  That is, the client must not run out of
data (buffer underrun) or accept more data than it can buffer
before playback (buffer overrun) as any excess media that cannot
be buffered is simply discarded.
Paragraph (version B):
Second, the client's consumption rate is limited not only by
bandwidth availability,but also media availability.  The client
cannot fetch media that is not available from a server yet.
Paragraph (version B):
A short description of streaming video characteristics in sd, to
set the stage for the rest of the document,
Paragraph (version B):
General guidance on bandwidth provisioning (bwprov) and latency
considerations (latency-cons) for streaming video delivery,
Paragraph (version B):
A description of adaptive encoding and adaptive delivery
techniques in common use for streaming video, along with a
description of the challenges media senders face in detecting the
bitrate available between the media sender and media receiver, and
collection of measurements by a third party for use in analytics
(sec-abr),
Paragraph (version B):
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
that we expect to be used for streaming media (sec-trans),
Paragraph (version B):
A number of useful pointers for further reading on this rapidly
changing subject (further).
Paragraph (version B):
Making specific recommendations on operational practices aimed at
mitigating the issues described in this document is out of scope,
though some existing mitigations are mentioned in passing.  The
intent is to provide a point of reference for future solution
proposals to use in describing how new technologies address or avoid
existing observed problems.
Paragraph (version B):
Much of the focus of this document is on reliable media using HTTP
over TCP. which is widely used because support for HTTP is widely
available in a wide range of operating systems, is also used in a
wide variety of other applications, has been demonstrated to provide
acceptable performance over the open Internet, includes state of the
art standardized security mechanisms, and can make use of already-
deployed caching infrastructure.
Paragraph (version B):
Some mentions of unreliable media delivery using RTP and other UDP-
based protocols appear in ultralow, unreliable, udp-behavior, and
hop-by-hop-encrypt, but it's difficult to give general guidance for
these applications.  For instance, when loss occurs, the most
appropriate response may depend on the type of codec being used.
Paragraph (version A):
Even basic virtual reality (360-degree) videos that allow users to
look around freely (referred to as "three degrees of freedom", or
3DoF) require substantially larger bitrates when they are captured
and encoded as such videos require multiple fields of view of the
scene.  The typical multiplication factor is 8 to 10.  Yet, due to
smart delivery methods such as viewport-based or tiled-based
streaming, we do not need to send the whole scene to the user.
Instead, the user needs only the portion corresponding to its
viewpoint at any given time.
Paragraph (version B):
Even basic virtual reality (360-degree) videos that allow users to
look around freely (referred to as "three degrees of freedom", or
3DoF) require substantially larger bitrates when they are captured
and encoded as such videos require multiple fields of view of the
scene.  Yet, due to smart delivery methods such as viewport-based or
tiled-based streaming, we do not need to send the whole scene to the
user.  Instead, the user needs only the portion corresponding to its
viewpoint at any given time (Survey360o).
Paragraph (version A):
To a receiver measuring bytes received per unit time at the
application layer, and interpreting it as an estimate of the
available network bandwidth, this appears as a high jitter in the
goodput measurement.  This can appear as a stall of some time,
followed by a sudden leap that can far exceed the actual capacity of
the transport path from the server when the hole in the received data
is filled by a later retransmission.
Paragraph (version B):
To a receiver measuring bytes received per unit time at the
application layer, and interpreting it as an estimate of the
available network bandwidth, this appears as a high jitter in the
goodput measurement, presenting as a stall, followed by a sudden leap
that can far exceed the actual capacity of the transport path from
the server when the hole in the received data is filled by a later
retransmission.
Paragraph (version A):
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.
Paragraph (version A):
As noted in tcp-behavior, there is increasing interest in transport
protocol behaviors that respond to delay measurements, instead of
responding to packet loss.  These behaviors may deliver improved user
experience, but in some cases have not responded to sustained packet
loss, which exhausts available buffers along the end-to-end path that
may affect other users sharing that path.  The QUIC protocol provides
a set of congestion control hooks that can be use for algorithm
agility, and RFC9002 defines a basic algorithm with transport
behavior that is roughly similar to TCP NewReno RFC6582.  However,
QUIC senders can and do unilaterally choose to use different
algorithms such as loss-based CUBIC RFC8312, delay-based COPA or BBR,
or even something completely different.
Paragraph (version B):
As noted in tcp-behavior, there is increasing interest in transport
protocol behaviors that respond to delay measurements, instead of
responding to packet loss.  These behaviors may deliver improved user
experience, but in some cases have not responded to sustained packet
loss, which exhausts available buffers along the end-to-end path that
may affect other users sharing that path.  The QUIC protocol provides
a set of congestion control hooks that can be used for algorithm
agility, and RFC9002 defines a basic algorithm with transport
behavior that is roughly similar to TCP NewReno RFC6582.  However,
QUIC senders can and do unilaterally choose to use different
algorithms such as loss-based CUBIC RFC8312, delay-based COPA or BBR,
or even something completely different.
Paragraph (version B):
It is worth considering that if TCP-based HTTP traffic and UDP-based
HTTP/3 traffic are allowed to enter operator networks on roughly
equal terms, questions of fairness and contention will be heavily
dependent on interactions between the congestion controllers in use
for TCP-based HTTP traffic and UDP-based HTTP/3 traffic.
Paragraph (version A):
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 describe the peculiarities of adaptive streaming
in low-latency live streaming scenarios.
Paragraph (version A):
Thanks to Alexandre Gouaillard, Aaron Falk, Dave Oran, Glenn Deen,
Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham, Matt Stock,
Mike English, Roni Even, and Will Law for very helpful suggestions,
reviews and comments.
Paragraph (version B):
Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran,
Glenn Deen, Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham,
Matt Stock, Mike English, Renan Krishna, Roni Even, and Will Law for
very helpful suggestions, reviews and comments.