Draft: draft-ietf-mops-streaming-opcons

Commentary: This tries to address both of : 
 Discussion from editor 's conference call : Can we provide a reference for useful properties ? Network analytics , application analytics , or both ? Currently application analytics , which is OK . Is that clear enough ? Who is supposed to notice changes from an expected baseline ? Is mentioning  helpful ? Have we said clearly enough that baselines themselves can fluctuate , before the kinds of path characteristic changes we 're talking about kick in ? 
 I think just " baseline " is clear enough to me , in context with this section listing some relevant stats . I guess " baseline pattern of some relevant statistics " is maybe more precise , but I 'm not sure " baseline pattern " really gets there . 
 from 's review ( ) 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 . 
 This comment helpfully points out the changing network architecture ( a LOT of wireless ) , and we should be clearer about what we 're talking about in Section 3.2 ( our mental was mostly wired ) and in 5.5.3 ( where we focused on wireless ) . This material should go in Section 3.2 , and should be referenced in 5.5.3 .. 
 Related to 
 From ( ) Section 3.2.1 . Recognizing Changes 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 , 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 . 
 Related to 
 This works for me . I 'll merge it .
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 .
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):
If cross traffic that also traverses part or all of the same path
topology increases or decreases, especially if this new cross
traffic is "inelastic," and does not, itself, respond to
indications of path congestion.
Paragraph (version A):
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 reliable-behavior
for more information.
Paragraph (version A):
As transport protocols evolve to encrypt their transport header
fields, one side effect of increasing encryption is the kind of
passive monitoring, or even "performance enhancement" (RFC3135) that
was possible with the older transport protocols (UDP, described in
unreliable-behavior and TCP, described in reliable-behavior) is no
longer possible with newer transport protocols such as QUIC
(described in quic-behavior).  The IETF has specified a "latency spin
bit" mechanism in Section 17.4 of RFC9000 to allow passive latency
monitoring from observation points on the network path throughout the
duration of a connection, but currently chartered work in the IETF is
focusing on endpoint monitoring and reporting, rather than on passive
monitoring.
Paragraph (version A):
One example is the "qlog" mechanism I-D.ietf-quic-qlog-main-schema, a
protocol-agnostic mechanism used to provide better visibility for
encrypted protocols such as QUIC (I-D.ietf-quic-qlog-quic-events) and
for HTTP/3 (I-D.ietf-quic-qlog-h3-events).
Paragraph (version B):
If cross traffic that also traverses part or all of the same path
topology increases or decreases, especially if this new cross
traffic is "inelastic," and does not respond to indications of
path congestion.
Paragraph (version B):
Wireless links (Wi-Fi, 5G, LTE, etc.) often see rapid changes to
capacity from changes in radio interference and signal strength as
endpoints move.
Paragraph (version B):
To recognize that a path carrying streaming media has experienced a
change, maintaining a baseline that captures its prior properties is
fundamental.  Analytics that aid in that recognition can be more or
less sophisticated and can usefully operate on several different time
scales, from milliseconds to hours or days.
Paragraph (version A):
As many end devices have moved to wireless connectivity for the final
hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detection have
emerged from radio interference and signal strength effects.
Paragraph (version A):
Each of these technologies can experience sudden changes in capacity
as the end user device moves from place to place and encounters new
sources of interference.  Microwave ovens, for example, can cause a
throughput degradation of more than a factor of 2 while active Micro.
5G and LTE likewise can easily see rate variation by a factor of 2 or
more over a span of seconds as users move around.
Paragraph (version A):
These swings in actual transport capacity can result in user
experience issues that can be exacerbated by insufficiently
responsive ABR algorithms.
Paragraph (version B):
As many end devices have moved to wireless connections for the final
hop (such as Wi-Fi, 5G, LTE, etc.), new problems in bandwidth
detection have emerged.
Paragraph (version B):
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.
Microwave ovens, for example, can cause a throughput degradation in
Wi-Fi of more than a factor of 2 while active Micro.  5G and LTE
likewise can easily see rate variation by a factor of 2 or more over
a span of seconds as users move around.
Paragraph (version B):
These swings in actual transport capacity can result in user
experience issues when interacting with ABR algorithms that aren't
tuned to handle the capacity variation gracefully.