Draft: draft-ietf-mops-streaming-opcons

Commentary: I went back through -11 and made sure we had at least tried to address each of your comments . Thank you for the careful read . 
 From 
 thank you for the review . On a quick read ( the authors have a conference call this afternoon my time ) , most of these are immediately actionable , and the ones that need a bit more discussion seem helpful and worth discussing . More news to follow , of course . 
 and - review has popped up some higher - level questions for me , that could be addressed in this issue , or in separate issues . I 'm keeping this list here , until our call in about 26 minutes . This document uses the word " media " about 200 times , and the word " video " about 70 times . I know I have n't been careful to use the best word in text I 've written . It 's probably worth doing a pass in the document to make sure that we say what we mean . Actually , are we mostly talking about " media " in general , and only mentioning " video " in specifics ? We only use the qualifier " high - bitrate " three times ( and two of these are in the abstract and introduction ) . That seems like an important qualifier . I think this document does include Video On Demand . Does anyone disagree ? We 've been saying that media delivery over RTP is " out of scope " , but the word " RTP " appears 12 times in the document . I think we 're including " interactive " , " live " , and " VoD " streaming media , and we probably need to say that clearly , early in the document . is there any difference , from the media provider 's perspective , if ( presumably high - bitrate ) media is streamed to be consumed by a machine ? Zahed has an excellent question - can we explain what 's different about ads , in about 1/4 the space ? sometimes we say " content provider " , and other times we say " media provider " . Is there a meaningful difference , or can we use the same term ? I 'm surprised that we only use the term " operator " three times , and even more surprised that these are n't all talking about the same thing , so that needs to be fixed ... 
 and - I 'm working through the high - level questions in my previous comment , and I have a few new ones . We never defined " high - bitrate " , although we ( now ) use the term in the abstract and in the Introduction . I 'm thinking about adding a pointer to the table of typical bitrates for various bitrates and resolutions in the " Video Bitrates " section , and saying " like , these bitrates " . 
 and - reasonably asked about a citation for this assertion in the draft : After poking around for a while , I 'm not seeing an obvious citation in open literature ( indexed by Google ) , specific to 5G. We do need to decide what to do with this one comment , before merging . 
 I probably wrote that text , and the reason I believed it was that it was discussed in I think a tsvwg or iccrg session talking about using chirping experimentally in conjunction with TCP Prague to find the link capacity , I think either by Ingemar or  . I now wish I could recall which meeting , or even which year I saw this . I do n't have a straight capacity metric , but I saw some stuff about attenuation and effects like shadow fading and path loss that I think are the physics reasons behind the 2nd - hand reported observation : Maybe we should strike the claim if we ca n't find a good source for it -- these 5 g docs talking about the relevant effects tend to speak in decibels rather than mbps , and it 's not clear to me exactly how they translate . 
 I 'd be astounded if no one at the IETF could speak to this , but in the references I could find , ISTM that there are all kinds of things that can affect pretty much any path traversing at least one wireless link . I removed the specific 5 G and  likewise can easily see rate variation by a factor of 2 or more over a span of seconds as users move around . , which I do n't think we can back up precisely , so now all the wireless - link paths are covered by an overarching In most real - world operating environments , wireless links can often experience sudden changes in capacity as the end user device moves from place to place or encounters new sources of interference . If that works for you , should be ready to review and ( if it 's OK ) merge . 
 on this comment , ( as an aside , I should mention that I do n't have any memory of active measurements being discussed in the working group for this document , but let 's ignore that , for now , and try to do the right thing ) I could n't think of a way to describe advantages of active testing that would work better than the measurement collection section for streaming media operators . Sure , active measurements can be the right thing to do , for operators providing access networks , etc .
Paragraph (version A):
It is worth pointing out explicitly because questions about "Web
Real-Time Communication (WebRTC)" has come up often, that some WebRTC
protocols (RFC8834, RFC8835) are mentioned in this document,
including RTP, WebRTC's principal media transport protocol.  However,
(as noted in sd) it is difficult to give general guidance for
unreliable media transport protocols used to carry interactive real-
time media.
Paragraph (version B):
It is worth pointing out explicitly because questions about "Web
Real-Time Communication (WebRTC)" has come up often, that RTP,
WebRTC's principal media transport protocol (RFC8834, RFC8835), is
mentioned in this document.  However, (as noted in sd) it is
difficult to give general guidance for unreliable media transport
protocols used to carry interactive real-time media.
Paragraph (version A):
Note that these codecs do not take the actual "available
bandwidth" between streaming video servers and streaming video
receivers into account when encoding because the codec does not
have any idea what network paths and network path conditions will
carry the encoded video at some point in the future.
Paragraph (version A):
Note that video receivers attempting to receive encoded video
across a network path with insufficient available path bandwidth
might request the video server to provide video encoded for lower
bitrates, as described in adapt-deliver.
Paragraph (version B):
Note that these codecs do not take the actual "available
bandwidth" between streaming video servers and streaming video
receivers into account when encoding because the codec does not
have any idea what network paths and network path conditions will
carry the encoded video at some point in the future.  It is common
for codecs to offer a small number of resource variants, differing
only in the bandwidth each variant targets.
Paragraph (version B):
Note that video receivers attempting to receive encoded video
across a network path with insufficient available path bandwidth
might request the video server to provide video encoded for lower
bitrates, at the cost of lower video quality, as described in
adapt-deliver.
Paragraph (version A):
the transport protocol cannot probe for available path bandwidth
by sending at a higher rate until the media receiver signals the
media server that the media server can increase its media segment
sending rate.
Paragraph (version B):
the transport protocol cannot probe for available path bandwidth
by sending at a higher rate until the media receiver requests
segments that buffer enough data for the transport to perform the
probing.