Draft: draft-ietf-mops-streaming-opcons

Commentary: these look fine . Thank you for the careful check ( and for removing so many of the commas I inserted without needing to ! )
Paragraph (version A):
Second, the client's media segment consumption rate is limited
not only by the path's available bandwidth, but also by media
segment availability.  The client cannot fetch media segments
that a media server cannot provide (yet).
Paragraph (version B):
Second, the client's media segment consumption rate is limited
not only by the path's available bandwidth but also by media
segment availability.  The client cannot fetch media segments
that a media server cannot provide (yet).
Paragraph (version A):
This document focuses chiefly on large-scale delivery of streaming
high-bitrate media to end users.  It is primarily intended for those
controlling endpoints involved in delivering streaming media traffic.
This can include origin servers publishing content, intermediaries
like content delivery networks (CDNs), and providers for client
devices and media players.
Paragraph (version B):
This document focuses chiefly on the large-scale delivery of
streaming high-bitrate media to end users.  It is primarily intended
for those controlling endpoints involved in delivering streaming
media traffic.  This can include origin servers publishing content,
intermediaries like content delivery networks (CDNs), and providers
for client devices and media players.
Paragraph (version A):
in-depth examination of real-time two-way interactive media, such
as video conferencing; although this document touches lightly on
topics related to this space, the intent is to let readers know
that for more in-depth coverage they should look to other
documents, since the techniques and issues for interactive real-
time two-way media differ so dramatically from those in large-
scale one-way delivery of streaming media.
Paragraph (version B):
in-depth examination of real-time two-way interactive media, such
as video conferencing; although this document touches lightly on
topics related to this space, the intent is to let readers know
that for more in-depth coverage, they should look to other
documents, since the techniques and issues for interactive real-
time two-way media differ so dramatically from those in large-
scale one-way delivery of streaming media.
Paragraph (version A):
transparent tunnels; while tunnels can have an impact on streaming
media via issues like the round trip time and the maximum
transmission unit (MTU) of packets carried over tunnels, for the
purposes of this document these issues are considered as part of
the set of network path properties.
Paragraph (version A):
It is worth pointing out explicitly, because questions about "Web
Real-Time Communication" or "WebRTC" have 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):
transparent tunnels; while tunnels can have an impact on streaming
media via issues like the round-trip time and the maximum
transmission unit (MTU) of packets carried over tunnels, for the
purposes of this document, these issues are considered as part of
the set of network path properties.
Paragraph (version B):
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 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 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.
Paragraph (version A):
The bitrates given in bvr describe video streams that provide the
user with a single, fixed, point of view - so, the user has no
"degrees of freedom," and the user sees all of the video image that
is available.
Paragraph (version B):
The bitrates given in bvr describe video streams that provide the
user with a single, fixed point of view - so, the user has no
"degrees of freedom," and the user sees all of the video image that
is available.
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 signals the
media server that the media server can increase its media segment
sending rate.
Paragraph (version A):
When demand for content is relatively predictable, and especially
when that content is relatively static, caching content close to
requesters and pre-loading caches to respond quickly to initial
requests is often useful (for example, HTTP/1.1 caching is described
in I-D.ietf-httpbis-cache).  This is subject to the usual
considerations for caching - for example, how much data must be
cached to make a significant difference to the requester and how the
benefits of caching and pre-loading caches balances against the costs
of tracking stale content in caches and refreshing that content.
Paragraph (version B):
When demand for content is relatively predictable, and especially
when that content is relatively static, caching content close to
requesters and pre-loading caches to respond quickly to initial
requests is often useful (for example, HTTP/1.1 caching is described
in RFC9111).  This is subject to the usual considerations for caching
- for example, how much data must be cached to make a significant
difference to the requester and how the benefit of caching and pre-
loading caches balances against the costs of tracking stale content
in caches and refreshing that content.
Paragraph (version A):
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 B):
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):
Historical data shows that users consume more videos and these videos
are encoded at a higher bitrate than they were in the past.
Improvements in the codecs that help reduce the encoding bitrates
with better compression algorithms could not have offset the increase
in the demand for the higher quality video (higher resolution, higher
frame rate, better color gamut, better dynamic range, etc.).  In
particular, mobile data usage has shown a large jump over the years
due to increased consumption of entertainment and conversational
video.
Paragraph (version B):
Historical data shows that users consume more videos and these videos
are encoded at a bitrate higher than they were in the past.
Improvements in the codecs that help reduce the encoding bitrates
with better compression algorithms could not have offset the increase
in the demand for the higher quality video (higher resolution, higher
frame rate, better color gamut, better dynamic range, etc.).  In
particular, mobile data usage has shown a large jump over the years
due to increased consumption of entertainment and conversational
video.
Paragraph (version A):
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 A):
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 A):
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 A):
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):
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 asymetric 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 the 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 RFC9075 in November 2020.  The following observations from
the workshop report are worth considering.
Paragraph (version A):
At DE-CIX Frankfurt, the world's largest Internet Exchange Point
in terms of data throughput, the year 2020 has seen the largest
increase in peak traffic within a single year since the IXP was
founded in 1995.
Paragraph (version B):
At DE-CIX Frankfurt, the world's largest IXP in terms of data
throughput, the year 2020 has seen the largest increase in peak
traffic within a single year since the IXP was founded in 1995.
Paragraph (version A):
Some internet applications that incorporate media streaming have
specific interactivity or control-feedback requirements that drive
much lower glass-to-glass media latency targets than one second.
These include videoconferencing or voice calls, remote video
gameplay, remote control of hardware platforms like drones, vehicles,
or surgical robots, and many other envisioned or deployed interactive
applications.
Paragraph (version B):
Some Internet applications that incorporate media streaming have
specific interactivity or control-feedback requirements that drive
much lower glass-to-glass media latency targets than one second.
These include videoconferencing or voice calls, remote video
gameplay, remote control of hardware platforms like drones, vehicles,
or surgical robots and many other envisioned or deployed interactive
applications.
Paragraph (version A):
While an LL-HLS client retrieves each chunk with a separate HTTP GET
request, an LL-DASH client uses the chunked transfer encoding feature
of the HTTP CMAF-CTE which allows the LL-DASH client to fetch all the
chunks belonging to a segment with a single GET request.  An HTTP
server can transmit the CMAF chunks to the LL-DASH client as they
arrive from the encoder/packager.  A detailed comparison of LL-HLS
and LL-DASH is given in MMSP20.
Paragraph (version B):
While an LL-HLS client retrieves each chunk with a separate HTTP GET
request, an LL-DASH client uses the chunked transfer encoding feature
of the HTTP CMAF-CTE, which allows the LL-DASH client to fetch all
the chunks belonging to a segment with a single GET request.  An HTTP
server can transmit the CMAF chunks to the LL-DASH client as they
arrive from the encoder/packager.  A detailed comparison of LL-HLS
and LL-DASH is given in MMSP20.
Paragraph (version A):
This section describes one of the best known ways to provide a good
user experience over a given network path, but one thing to keep in
mind is that application-level mechanisms cannot provide a better
experience than the underlying network path can support.
Paragraph (version B):
This section describes one of the best-known ways to provide a good
user experience over a given network path, but one thing to keep in
mind is that application-level mechanisms cannot provide a better
experience than the underlying network path can support.
Paragraph (version A):
This ecosystem balances several competing objectives, and integrating
with it naively can produce surprising user experience results.  For
example, ad server provisioning and/or the bitrate of the ad segments
might be different from that of the main video, and either of these
differences can result in video stalls.  For another example, since
the inserted ads are often produced independently, they might have a
different base volume level than the main video, which can make for a
jarring user experience.
Paragraph (version B):
This ecosystem balances several competing objectives and integrating
with it naively can produce surprising user experience results.  For
example, ad server provisioning and/or the bitrate of the ad segments
might be different from that of the main video, and either of these
differences can result in video stalls.  For another example, since
the inserted ads are often produced independently, they might have a
different base volume level than the main video, which can make for a
jarring user experience.
Paragraph (version A):
Another major source of competing objectives comes from user privacy
considerations vs. the advertiser's incentives to target ads to user
segments based on behavioral data.  Multiple studies, for example
BEHAVE and BEHAVE2, have reported large improvements in ad
effectiveness when using behaviorally targeted ads, relative to
untargeted ads.  This provides a strong incentive for advertisers to
gain access to the data necessary to perform behavioral targeting,
leading some to engage in what is indistinguishable from a pervasive
monitoring attack (RFC7258) based on user tracking in order to
collect the relevant data, A more complete review of issues in this
space is available in BALANCING.
Paragraph (version B):
Another major source of competing objectives comes from user privacy
considerations vs. the advertiser's incentives to target ads to user
segments based on behavioral data.  Multiple studies, for example,
BEHAVE and BEHAVE2, have reported large improvements in ad
effectiveness when using behaviorally targeted ads, relative to
untargeted ads.  This provides a strong incentive for advertisers to
gain access to the data necessary to perform behavioral targeting,
leading some to engage in what is indistinguishable from a pervasive
monitoring attack (RFC7258) based on user tracking in order to
collect the relevant data, A more complete review of issues in this
space is available in BALANCING.
Paragraph (version A):
In turn, media providers may base analytics on these measurements, to
guide decisions such as whether adaptive encoding bitrates in use are
the best ones to provide to media players, or whether current media
content caching is providing the best experience for viewers.
Paragraph (version B):
In turn, media providers may base analytics on these measurements to
guide decisions such as whether adaptive encoding bitrates in use are
the best ones to provide to media players, or whether current media
content caching is providing the best experience for viewers.
Paragraph (version A):
RTP RFC3550, which can notice packetloss and repair some limited
reordering,
Paragraph (version B):
RTP RFC3550, which can notice packet loss and repair some limited
reordering,
Paragraph (version A):
A QUIC extension currently being specified (I-D.ietf-quic-datagram)
adds the capability for "unreliable" delivery, similar to the service
provided by UDP, but these datagrams are still subject to the QUIC
connection's congestion controller, providing some transport-level
congestion avoidance measures, which UDP does not.
Paragraph (version B):
A QUIC extension currently being specified (RFC9221) adds the
capability for "unreliable" delivery, similar to the service provided
by UDP, but these datagrams are still subject to the QUIC
connection's congestion controller, providing some transport-level
congestion avoidance measures, which UDP does not.