Draft: draft-ietf-mops-streaming-opcons

Commentary: Fixed a few typos , otherwise ready to merge . 
 Merging on  's review . 
 From ( ) ( In 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 .
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):
All of this depends, of course, on the ability of a content provider
to predict usage and provision bandwidth, caching, and other
mechanisms to meet the needs of users.  In some cases (sec-predict),
this is relatively routine, but in other cases, it is more difficult
(sec-unpredict, sec-extreme).
Paragraph (version B):
All of this depends, of course, on the ability of a content provider
to predict usage and provision bandwidth, caching, and other
mechanisms to meet the needs of users.  In some cases (sec-predict),
this is relatively routine, but in other cases, it is more difficult
(sec-unpredict).
Paragraph (version A):
And as with other parts of the ecosystem, new technology brings new
challenges.  For example, with the emergence of ultra-low-latency
streaming, responses have to start streaming to the end user while
still being transmitted to the cache, and while the cache does not
yet know the size of the object.  Some of the popular caching systems
were designed around cache footprint and had deeply ingrained
assumptions about knowing the size of objects being stored, so the
change in design requirements in long-established systems caused some
errors in production.  Incidents occurred where a transmission error
in the connection from the upstream source to the cache could result
in the cache holding a truncated segment and transmitting it to the
end user's device.  In this case, players rendering the stream often
had the video freeze until the player was reset.  In some cases the
truncated object was even cached that way and served later to other
players, causing continued stalls at the same spot in the video for
all players playing the segment delivered from that cache node.
Paragraph (version B):
And as with other parts of the ecosystem, new technology brings new
challenges.  For example, with the emergence of ultra-low-latency
streaming, responses have to start streaming to the end user while
still being transmitted to the cache, and while the cache does not
yet know the size of the object.  Some of the popular caching systems
were designed around cache footprint and had deeply ingrained
assumptions about knowing the size of objects that are being stored,
so the change in design requirements in long-established systems
caused some errors in production.  Incidents occurred where a
transmission error in the connection from the upstream source to the
cache could result in the cache holding a truncated segment and
transmitting it to the end user's device.  In this case, players
rendering the stream often had the video freeze until the player was
reset.  In some cases the truncated object was even cached that way
and served later to other players as well, causing continued stalls
at the same spot in the video for all players playing the segment
delivered from that cache node.
Paragraph (version A):
Although TCP/IP has been used with a number of widely used
applications that have symmetric bandwidth requirements (similar
bandwidth requirements in each direction between endpoints), many
widely-used Internet applications operate in client-server roles,
with asymmetric bandwidth requirements.  A common example might be an
HTTP GET operation, where a client sends a relatively small HTTP GET
request for a resource to an HTTP server and often receives a
significantly larger response carrying the requested resource.  When
HTTP is commonly used to stream movie-length videos, the ratio
between response size and request size can become arbitrarily large.
Paragraph (version A):
For this reason, operators may pay more attention to downstream
bandwidth utilization when planning and managing capacity.  In
addition, operators have been able to deploy access networks for end
users using underlying technologies that are inherently asymmetric,
favoring downstream bandwidth (e.g., ADSL, cellular technologies,
most IEEE 802.11 variants), assuming that users will need less
upstream bandwidth than downstream bandwidth.  This strategy usually
works, except when it fails because application bandwidth usage
patterns have changed in ways that were not predicted.
Paragraph (version A):
One example of this type of change was when peer-to-peer file-sharing
applications gained popularity in the early 2000s.  To take one well-
documented case (RFC5594), the BitTorrent application created
"swarms" of hosts, uploading and downloading files to each other,
rather than communicating with a server.  BitTorrent favored peers
who uploaded as much as they downloaded, so new BitTorrent users had
an incentive to significantly increase their upstream bandwidth
utilization.
Paragraph (version A):
The combination of the large volume of "torrents" and the peer-to-
peer characteristic of swarm transfers meant that end user hosts were
suddenly uploading higher volumes of traffic to more destinations
than was the case before BitTorrent.  This caused at least one large
Internet service provider (ISP) to attempt to "throttle" these
transfers to mitigate the load these hosts placed on their network.
These efforts were met by increased use of encryption in BitTorrent,
and complaints to regulators calling for regulatory action.
Paragraph (version A):
The BitTorrent case study is just one example.  However, the example
is included here to make it clear that unpredicted and unpredictable
massive traffic spikes may not be the result of natural disasters,
but they can still have significant impacts.
Paragraph (version A):
Especially as end users increasingly use video-based social
networking applications, it will be helpful for access network
providers to watch for increasing numbers of end users uploading
significant amounts of content.
Paragraph (version A):
The causes of unpredictable usage described in sec-unpredict were
more or less the result of human choices.  However, we were reminded
during a post-IETF 107 meeting that humans are not always in control,
and forces of nature can cause enormous fluctuations in traffic
patterns.
Paragraph (version A):
In his talk, Sanjay Mishra Mishra reported that after the COVID-19
pandemic broke out in early 2020,
Paragraph (version A):
Comcast's streaming and web video consumption rose by 38%, with
their reported peak traffic up 32% overall between March 1 to
March 30,
Paragraph (version A):
Verizon reported similar trends with video traffic up 36% over an
average day (pre COVID-19)}.
Paragraph (version A):
Weekday peak traffic increases over 45%-50% from pre-lockdown
levels,
Paragraph (version A):
Subsequently, the Internet Architecture Board (IAB) held a COVID-19
Network Impacts Workshop IABcovid in November 2020.  Given a larger
number of reports and more time to reflect, the following
observations from the draft workshop report are worth considering.
Paragraph (version B):
It is also possible for usage profiles to change significantly and
suddenly.  These changes are more difficult to plan for, but at a
minimum, recognizing that sudden changes are happening is critical.
Paragraph (version B):
Two examples are instructive.
Paragraph (version B):
Many access networks for end users used underlying technologies
that are inherently asymmetric, favoring downstream bandwidth
(e.g.  ADSL, cellular technologies, most IEEE 802.11 variants),
assuming that most users will need more downstream bandwidth than
upstream bandwidth.  This is a good assumption for client-server
applications such as streaming video or software downloads, but
BitTorrent rewarded peers that uploaded as much as they
downloaded, so BitTorrent users had much more symmetric usage
profiles which interacted badly with these assymetric access
network technologies.
Paragraph (version B):
BitTorrent also used distributed hash tables to organize peers
into a ring topology, where each peer knew its "next peer" and
"previous peer".  There was no connection between the application-
level ring topology and the lower-level network topology, so a
peer's "next peer" might be anywhere on the reachable Internet.
Traffic models that expected most communication to take place with
a relatively small number of servers were unable to cope with
peer-to-peer traffic that was much less predictable.
Paragraph (version B):
Especially as end users increase use of video-based social networking
applications, it will be helpful for access network providers to
watch for increasing numbers of end users uploading significant
amounts of content.
Paragraph (version B):
Early in 2020, the CoViD-19 pandemic and resulting quarantines and
shutdowns led to significant changes in traffic patterns, due to a
large number of people who suddenly started working and attending
school remotely and using more interactive applications (video
conferencing, in addition to streaming media).  Subsequently, the
Internet Architecture Board (IAB) held a COVID-19 Network Impacts
Workshop IABcovid in November 2020.  The following observations from
the workshop report are worth considering.
Paragraph (version B):
Again, it will be helpful for streaming operators to monitor traffic
as described in measure-coll, watching for sudden changes in
performance.