Draft: draft-ietf-mops-streaming-opcons

Commentary: From Same comment as for section 1 , " networking issues " actually means something broader than the plain layer-3 . Suggest introducing the shortcut in the terminology part of section 1 , e.g. , " this document uses the wording networking issues to represent the conjunction of IP and transport layers " ? 
 Hi , I thought this might be a quick addition of an umbrella definition of " networking " to include transport protocols , but a significant chunk of the text was distinguishing between network and transport protocols , so I " and transport protocols " to the few occurrences of " networking " that were intended to include both . 
 Thank you , , this is more work for the authors but less ambiguous for the readers . 
 From Unsure whether " server - player systems " is well understood by the readers . Nit : " some metric monitored by the client " should the plural form be used ? 
 I do nt think we made the exercise of going thru all the mixed - up terms like clients vs. players in the text . One simple solution is to do the following : ( streaming ) client : the part of the ( media ) player that deals with the transmission / reception and buffer related matters . ( media ) player : on top of the streaming client , this includes the media decoders , UI , user controls , DRM , authentication modules , etc . 
 " many systems " - 
 From " Know Your Network Traffic " what is " your " in this section ? My network used by other parties ( server and consumer ) to transfer streaming video ? My network as the servers ,  , and consumers are all in my administrative domain ? Suggest removing the ' your ' 
 Knowing expected traffic and traffic growth baselines before something goes wrong . 
 From While I am not an expert , I am surprised by the acceptable latency numbers , I would have written 100 msec for videoconference and " couple of seconds " for streaming live events . Video streaming ( netflix like ) is indeed several seconds . But , I am trusting the authors on their statement . Section 4.2 explains a little more those numbers so a forward reference to section 4 would be beneficial . 
 On - list discussion so far concluded that we are best off leaving it alone , with no dissent yet : 
 I 've raised this issue a few times , but suspect that the right answer is to Do n't change any of the numbers in this document , Recognize that latency goals are falling year by year , and Wait until we better understand the thinking in MOQ discussions about the latency requirements for live media streaming and other forms of media handling to revisit this The likely improvements from continued discussions about latency categories are n't worth holding up this document . 
 Up to the authors , really , but suggest to add some text about those numbers are in flux ? 
 Yeah , that sounds like a good idea . Some clarifying context in the section 4 header where these numbers appear might help avoid some confusion . 
 - that sounds like a win to me . My goal was to NOT say something like " these numbers are old and inaccurate , so good luck ! " 
 We agree with the suggestion for forward reference to Section 4 . 
 LGTM
Mailing list commentary: Hi , , I agree . I know that 's why I ' m reacting now . and I are reacting specifically about the 1 second for videoconferencing , which is clearly wrong , because we ' ve known that people accidentally talk over other people when latencies are more than 200 ms for decades , but it 's probably not wrong enough to be worth talking about changing it . Honestly , if this document is about Operational Considerations for Streaming Media , anyone reading it for guidance about videoconferencing probably has bigger problems than the latency categories . You have convinced me even after convinced me . I think we 're through discussing that part , at least for now . Best ,
Paragraph (version A):
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):
This document examines networking and transport protocol 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 A):
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):
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 additional discussion of
latency requirements, see latency-cons.
Paragraph (version A):
Recognizing that a path carrying streaming media is "not behaving the
way it normally does" is fundamental.  Analytics that aid in that
recognition can be more or less sophisticated, and can be as simple
as noticing that the apparent round trip times for media traffic
carried over TCP transport on some paths are suddenly and
significantly longer than usual.  Passive monitors can detect changes
in the elapsed time between the acknowledgements for specific TCP
segments from a TCP receiver, since TCP octet sequence numbers and
acknowledgements for those sequence numbers are "carried in the
clear", even if the TCP payload itself is encrypted.  See tcp-
behavior for more information.
Paragraph (version B):
In order to recognize that a path carrying streaming media is "not
behaving the way it normally does", having an expected baseline that
describes "the way it normally does" is fundamental.  Analytics that
aid in that recognition can be more or less sophisticated, and can be
as simple as noticing that the apparent round trip times for media
traffic carried over TCP transport on some paths are suddenly and
significantly longer than usual.  Passive monitors can detect changes
in the elapsed time between the acknowledgements for specific TCP
segments from a TCP receiver, since TCP octet sequence numbers and
acknowledgements for those sequence numbers are "carried in the
clear", even if the TCP payload itself is encrypted.  See tcp-
behavior for more information.
Paragraph (version A):
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 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
some metric monitored by the client, such as 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 a 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 B):
The choice of bitrate occurs within the context of optimizing for one
or more metrics monitored by the client, such as highest achievable
video quality or lowest chances for a rebuffering event (playback
stall).
Paragraph (version A):
This kind of bandwidth-measurement system can experience trouble in
several ways that are affected by networking issues.  Because
adaptive application-level response strategies are often using rates
as observed by the application layer, there are sometimes inscrutable
transport-level protocol behaviors that can produce surprising
measurement values when the application-level feedback loop is
interacting with a transport-level feedback loop.
Paragraph (version B):
This kind of bandwidth-measurement system can experience trouble in
several ways that are affected by networking and transport protocol
issues.  Because adaptive application-level response strategies are
often using rates as observed by the application layer, there are
sometimes inscrutable transport-level protocol behaviors that can
produce surprising measurement values when the application-level
feedback loop is interacting with a transport-level feedback loop.