Draft: draft-ietf-mops-streaming-opcons

Commentary: several things here . we probably do n't need all of the descriptive text - the idea is that we 'd say " assume roughly this protocol stack , and here 's what 's not included " if distinguishing between " transport protocol " and " media transport protocol " makes sense , that probably needs to be reflected elsewhere in the document ( like , a lot of elsewheres ) If this approach works , it could either be in the transport protocol section , or in the one you 're thinking of for 
 I do n't think there will be a lot of places . We need to pay attention to only the places where we are explicitly referring to the media transport protocol . The rest can stay the same IMO . 
 I could n't reply to this inline , but I looked through the document ( searching for " transport protocol " , and you 're right . I found one place in Section 4.1 , and changed the description of RTP as a transport protocol to RTP as a media transport protocol . - Section 4.1 is before where my explanation is now - if this PR makes sense to you , the explanation probably DOES belong much earlier in the doc , perhaps in . 
 I 'm merging this , based on  's review . 
 We want a paragraph to say something about scope along the lines of : This document is for endpoints delivering streaming media traffic . This can include intermediaries like CDNs as well as content owners and end users , plus their device and player providers . We think this can help address a few issues from last call / iesg review , including : ( more to be linked as we notice them ) 
 Consider adding a subsection in the introduction about things that are out of scope , and ( for extra credit ) , why they are out of scope . 

 from 's review ( ) Section 6.1 . UDP and Its Behavior UDP is also used for encrypted tunnels ( OpenVPN , Wireguard , etc . ) . Does encrypted tunneling really have no operational impact on streaming apps other than circuit breakers ? ( I am thinking about 4 K streaming over OpenVPN and the like . ) 
 Not sure if this is really about scope clarification ? I think this section is intending to talk about usage as part of a transport protocol , but tunnels are sort of more like a path overlay issue or something ( might affect mtu , extra hops with extra things that can go wrong , etc . ) . 
 - I 'm looking more closely at this issue , and I think text that I put in another ( individual ) draft may be useful here as well . I 'll add it in this section ( making the obvious substitutions ) , and I 'll see what and think ( after the holiday weekend ) , and then check back with you . If it works for people , the result will likely be clearer to many readers .
Mailing list commentary: Reviewer : Review result : Ready with Issues This document has been reviewed as part of the transport area review team 's ongoing effort to review key IETF documents . These comments were written primarily for the transport area directors , but are copied to the document 's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information . When done at the time of IETF Last Call , the authors should consider this review as part of the last - call comments they receive . Please always CC tsv- if you reply to or forward this review . This informational document surveys network and transport protocol issues that affect quality of experience for streaming applications , in particular video . The overview covers many topics across different technologies . Readers may only be familiar with a subset of these topics and could therefore learn quite a bit from this kind of tutorial . Nonetheless , it remains somewhat unclear what the actual objective of some of the text is . For some topics , quite a bit of technical background is provided , but the discussion is not really comprehensive . In many sections , the document neither derives technical challenges , nor system / protocol requirements , nor practical usage guidance . It is just a kind of tutorial . Quite a bit of text also presents ongoing IETF work , and an RFC with this scope may thus get outdated soon . Section 6.2 deals with topics owned by TCPM . In similar past documents , I have asked for a TCPM presentation prior to an IETF last call in order to ensure that owners of running code are in the loop . I believe this strategy has worked well in the past . Having said this , as TSV - ART reviewer I do n't strongly disagree with a publication . All these issues may just be OK for an informational RFC . Some more specific comments : Section 3.2.1 . from an Expected Baseline This section apparently assumes relatively static path properties , e.g. , fixed network connectivity . It would be more useful to analyze the impact of and 4G/5 G networks in one place . Some of this follows later in sections 3.2.1 and 5.5.3 . Yet , the split between these three sections is unclear . Having a discussion about today 's Internet path characteristics and the dynamics at one place could be more useful . The text could also better distinguish between what matters to endpoints and considerations relevant only for middleboxes ( such as passive monitors ) . Section 3.3 Path Requirements The statement " to find the bandwidth requirements for a router on the delivery path " may assume that the bottleneck on the path will be routers . Yet , on a path the bottlenecks could also be a link layer device ( e.g. , an   , a access point , etc . ) . RFC 6077 ( specifically Section 3.1.3 ) also explains that issue . A better wording may be " to find the bandwidth requirements for a delivery path " . Section 3.6 . Unpredictable Usage Profiles / Section 3.7 . Extremely Unpredictable Usage Profiles I am not fully convinced by the distinction between " unpredictable " and " extremely unpredictable " . To me , these two sections could be merged and maybe also be shortened . More specifically , Section 3.7 lists a lot of statistics from the past . What is IMHO a bit missing in Section 3.7 are actual operational considerations . For instance , are there any lessons learnt for the future ? Note that Section 3.6 has a reasonable conclusion at the end . Section 4 . Latency Considerations and Section 4.1 . I am surprised by the definition " ultra low - latency ( less than 1 second ) " , as well as some of the other numbers . For other real - time communication use cases , " ultra low - latency " would probably imply a latency requirement of the order of one millisecond . For instance , isochronous traffic for motion control in industrial networks may require a latency of 1 ms , and such " ultra - low latency " requirements are discussed elsewhere , e.g. , in the DetNet WG . The terminology in this section should be better explained to readers dealing with networked systems with much harder latency requirements . And a reference should be for these definitions in the context of video streaming . Section 5.5.2 Head - of - Line Blocking If Head - of - Line Blocking is indeed a relevant operational problem , it would be useful to add a corresponding reference ( e.g. , with measurements ) . Section 5.5.3 . Wide and Rapid Variation in Path Capacity The statement " As many end devices have moved to wireless connectivity for the final hop ( Wi - Fi , 5 G , or LTE ) , new problems in bandwidth detction have emerged from radio interference and signal strength effects . " could be moved to earlier parts of the document . Quite a bit of new computers apparently only have connectivity and no Ethernet port , i.e. , may just be their default . Also , wireless may not only be used on the last hop , for instance in meshed setups . This may make the problem even harder . Section 6 . Evolution of Transport Protocols and Transport Protocol Behaviors I really wonder whether UDP vs. vs. QUIC is actually the relevant distinction . What may actually matter are the transport services provided by the protocol stack ( e.g. , RFC 8095 ) . I fully agree to a related comment in the INTDIR review . Section 6.1 . UDP and Its Behavior UDP is also used for encrypted tunnels ( OpenVPN , Wireguard , etc . ) . Does encrypted tunneling really have no operational impact on streaming other than circuit breakers ? ( I am thinking about 4 K streaming over OpenVPN and the like . ) Section 6.2 . TCP and Its Behavior This text should IMHO be presented and be discussed in TCPM . Personally , I am not convinced that this document is a good place for discussing the long history of TCP congestion control . If the objective of the document is to provide a tutorial , IMHO it would be more useful to briefly explain the state - of - the - art in year 2022 . Some further specific comments on TCP congestion control : It is surprising that RFC 5681 is not referenced .793bis has normative statements regarding congestion control , and most stacks are compatible to what is written in 793bis . Several operating systems use CUBIC by default and support standard Reno . Another general good reference for TCP standards is RFC 7414 .Does ECN , DCTCP , etc . really not matter at all , for instance , if a data center hosts video playout servers ? Section 6.3 . QUIC and Its Behavior As already noted , the discussion about head - of - line - blocking would really benefit from backing by a reference . Section 7 . Streaming Encrypted Media As far as I know , streaming users sometimes use encrypted tunnels such as OpenVPN or WireGuard ( or IPsec ) to access video content . I may miss something , but it is unclear to me how that fits into the categories presented in Section 7 .
Paragraph (version A):
Most applications operating over IP networks and requiring latency
this low use the Real-time Transport Protocol (RTP) RFC3550 or WebRTC
RFC8825, which uses RTP for the media transport as well as several
other protocols necessary for safe operation in browsers.
Paragraph (version B):
Most applications operating over IP networks and requiring latency
this low use the Real-time Transport Protocol (RTP) RFC3550 or WebRTC
RFC8825, which uses RTP as its Media Transport Protocol, along with
several other protocols necessary for safe operation in browsers.
Paragraph (version B):
"Media Format" would be something like an RTP payload format
RFC2736 or ISOBMFF ISOBMFF,
Paragraph (version B):
"Transport Protocol" would be something like TCP or UDP.
Paragraph (version B):
It is worth noting explicitly that the Media Transport Protocol and
Transport Protocol layers might each include more than one protocol.
For example, a Media Transport Protocol might run over HTTP, or over
WebTransport, which in turn runs over HTTP.
Paragraph (version B):
It is worth noting explicitly that more complex network protocol
stacks are certainly possible - for instance, packets with this
protocol stack may be carried in a tunnel, or in a VPN.  If these
environments are present, streaming media operators may need to
analyze their effects on applications as well.