Draft: draft-ietf-mops-streaming-opcons

Commentary: is this roughly what you were expecting to see , on Issue 22 ? Please advise :-) 
 I 'm having a conversation with about , but the short summary here is that I need to tighten up some of the language about what we are saying about strangely HTTPish UDP traffic , from an observer 's perspective , and to do so without starting to say things that either duplicate ( bad ) or contradict ( worse ) the QUIC manageability draft on this point . You 'll note that the QUIC issue is still under discussion , so probably need to revisit this after they close their Issue . Fortunately , I bet will make sure I behave ... and I appreciate that . 
 Is it worth also saying about the expectations networks allows streaming traffic over TCP and QUIC to flow freely ? I think this could just be a short paragraph that highlights that when other variables are isolated , fairness / contention between TCP and QUIC is most likely a function of the congestion controllers at play . 
 I THINK the current text in this draft ( as of 10 May ) is consistent with the QUIC manageability draft , but it will be GREAT for us to do a final check after QUIC finishes working on their draft . 
 thank you for this suggestion . See what you think of the current text . 
 And , like magic , this just popped up on the QUIC mailing list 15 minutes ago . I swear , I could write this script ! " The SNI extraction and Appendix A sections of manageability provide guidance that wo n't work with  . I opened issues 357 and 358 about this . They should be easy to resolve . I apologize for the late notice ( I have n't been keeping track of these documents closely ) but I do think these do need to be addressed before publication . " 
 The text LGTM . I 'll leave it to you editors to decide and battle out where / if to land it . 
 I 'm going to do a commit that moves this text to an actual reasonable place in the draft ( I 'll be looking at your suggestion to put it near ABR , and I 'll try to Do The Right Thing ) . Probably best not to merge this PR until I commit that , OK ? 
 and I think this PR is ready to merge . Do either of you agree ? 
 Since the intro says relate to quality of experience in internet video delivery . I 'm a little surprised to not see anything about the effects on video QoE caused by contention in the network , or the role that fairness between other flows and/or protocols plays on video and other applications . Finally , its been interesting to see how large content providers have reduced streaming bitrates in response to large - scale contention during the COVID pandemic , whether voluntarily or via external pressures . This is especially curious when content is distributed via ABR technologies which should accommodate switching to lower bitrates . ( I 've heard anecdotal reasoning that the detection of contention is too slow , but unsure if that is really true ) . 
 One of the more logical explanations of the situation I have I read : EU asking Netflix to drop the bitrates was a total BS IMO . 
 It is worth noting that some protocols rely on the transport layer bwe / cc ( the ones that are TCP based ) while others have to implement their own mechanisms ( udp based like QUIC or RTP ) . In that regard , I would differentiate the loss based bwe / cc algorithms ( TCP , new Reno , bbr ) vs the delay based ones ( copa ) . 
 I 'm planning to focus a PR for this issue on fairness and contention , but defer to the " Extremely Unpredictable Usage Profiles " section , which we 've recently merged into Master , for anything about CoViD-19 - related impacts on network performance for streaming media . Please let me know if that 's not a good plan . 
 OK , I 'm about 10 commits ( it seemed like more ) into the PR for this issue , and am now thinking that I should divide what is now the " Evolution of Transport Protocols and Transport Protocol Behaviors " section into a UDP / TCP section that comes before the ABR section , because those are the protocols that people use with ABR today , and a QUIC section ( that is actually " evolution " ) that remains after the ABR section . and do you have any thoughts about that ? I 'm pretty sure it would allow us to tighten up the discussion of interaction between ABR and transport protocol behavior in the ABR section . 
 Sounds reasonable to me , I think . 
 I 'll make that split ( and see if I can do that without conflicts - I think I 'm only moving text in , so should be easy . 
 The content here is pretty good , but I think maybe goes a little out of scope for what I thought this doc should do . I 'd be in favor of more depth on the effects of congestion on video QoE. I 'm agnostic on whether to drop some of the depth here on congestion control in general ( it 's good stuff , but reading it I feel like this is for an iccrg informational topic instead of a mops one . ) Also the section location seems to be the first one after the intro . Should this move into the ABR section , maybe with a note about congestion response being the primary driver for ABR bitrate selection ?
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):
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 B):
The use of strong encryption does provide confidentiality for
encrypted streaming media, from the sender to either an intermediary
or the ultimate media consumer, and this does prevent Deep Packet
Inspection by any intermediary that does not possess credentials
allowing decryption.  However, even encrypted content streams may be
vulnerable to traffic analysis.  An intermediary that can identify an
encrypted media stream without decrypting it, may be able to
"fingerprint" the encrypted media stream of known content, and then
match the targeted media stream against the fingerprints of known
content.  This protection can be lessened if a media provider is
repeatedly encrypting the same content. codaspy is an example of what
is possible when identifying HTTPS-protected videos over TCP
transport, based either on the length of entire resources being
transferred, or on characteristic packet patterns at the beginning of
a resource being transferred.
Paragraph (version B):
Although the IETF has put considerable emphasis on end-to-end
streaming media encryption, there are still important use cases that
require the insertion of intermediaries.
Paragraph (version B):
There are a variety of ways to involve intermediaries, and some are
much more intrusive than others.
Paragraph (version B):
Server And Network assisted DASH DASH-SAND - this specification
introduces explicit messaging between DASH clients and network
elements or between various network elements for the purpose of
improving the efficiency of streaming sessions by providing
information about real-time operational characteristics of
networks, servers, proxies, caches, CDNs, as well as DASH client's
performance and status.
Paragraph (version B):
"Double Encryption Procedures for the Secure Real-Time Transport
Protocol (SRTP)" RFC8723 - this specification provides a
cryptographic transform for the Secure Real-time Transport
Protocol that provides both hop-by-hop and end-to-end security
guarantees.