Draft: draft-ietf-mops-streaming-opcons

Commentary: good catch . He 's now .
Paragraph (version A):
In many contexts, video traffic can be handled transparently as
generic application-level traffic.  However, as the volume of video
traffic continues to grow, it's becoming increasingly important to
consider the effects of network design decisions on application-level
performance, with considerations for the impact on video delivery.
Paragraph (version A):
Much of the focus of this document is on reliable media using HTTP
over TCP. which is widely used because support for HTTP is widely
available in a wide range of operating systems, is also used in a
wide variety of other applications, has been demonstrated to provide
acceptable performance over the open Internet, includes state of the
art standardized security mechanisms, and can make use of already-
deployed caching infrastructure.
Paragraph (version A):
Some mentions of unreliable media delivery using RTP and other UDP-
based protocols appear in ultralow, unreliable, udp-behavior, and
hop-by-hop-encrypt, but it's difficult to give general guidance for
these applications.  For instance, when loss occurs, the most
appropriate response may depend on the type of codec being used.
Paragraph (version B):
In many contexts, video traffic can be handled transparently as
generic application-level traffic.  However, as the volume of video
traffic continues to grow, it is becoming increasingly important to
consider the effects of network design decisions on application-level
performance, with considerations for the impact on video delivery.
Paragraph (version B):
support for HTTP is widely available in a wide range of operating
systems,
Paragraph (version B):
HTTP is also used in a wide variety of other applications,
Paragraph (version B):
HTTP has been demonstrated to provide acceptable performance over
the open Internet,
Paragraph (version B):
HTTP can make use of already-deployed caching infrastructure.
Paragraph (version B):
Unreliable media delivery using RTP and other UDP-based protocols is
also discussed in ultralow, unreliable, udp-behavior, and hop-by-hop-
encrypt, but it is difficult to give general guidance for these
applications.  For instance, when loss occurs, the most appropriate
response may depend on the type of codec being used.
Paragraph (version A):
It is worth noting that not all high-demand content is "live"
content.  One popular example is when popular streaming content can
be staged close to a significant number of requesters, as can happen
when a new episode of a popular show is released.  This content may
be largely stable, so low-cost to maintain in multiple places
throughout the Internet.  This can reduce demands for high end-to-end
bandwidth without having to use mechanisms like multicast.
Paragraph (version B):
It is worth noting that not all high-demand content is "live"
content.  One relevant example is when popular streaming content can
be staged close to a significant number of requesters, as can happen
when a new episode of a popular show is released.  This content may
be largely stable, so low-cost to maintain in multiple places
throughout the Internet.  This can reduce demands for high end-to-end
bandwidth without having to use mechanisms like multicast.
Paragraph (version A):
Historical data shows that users consume more video and videos at
higher bitrates than they did in the past on their connected devices.
Improvements in the codecs that help with reducing 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 as
well as conversational video.
Paragraph (version B):
Historical data shows that users consume more videos and at a higher
bit rate than they did in the past on their connected devices.
Improvements in the codecs that help with reducing 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 as
well as conversational video.
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 that these hosts placed on their
network.  These efforts were met by increased use of encryption in
Bittorrent, similar to an arms race, and set off discussions about
"Net Neutrality" and calls for regulatory action.
Paragraph (version B):
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 in order to to mitigate the load that these hosts placed on
their network.  These efforts were met by increased use of encryption
in Bittorrent, similar to an arms race, and set off discussions about
"Net Neutrality" and calls for regulatory action.
Paragraph (version A):
Applications requiring low-latency live media delivery are generally
feasible at scale with some restrictions.  This typically requires
the use of a premium service dedicated to the delivery of live video,
and some tradeoffs may be necessary relative to what's feasible in a
higher latency service.  The tradeoffs may include higher costs, or
delivering a lower quality video, or reduced flexibility for adaptive
bitrates, or reduced flexibility for available resolutions so that
fewer devices can receive an encoding tuned for their display.  Low-
latency live delivery is also more susceptible to user-visible
disruptions due to transient network conditions than higher latency
services.
Paragraph (version B):
Applications requiring low-latency live media delivery are generally
feasible at scale with some restrictions.  This typically requires
the use of a premium service dedicated to the delivery of live video,
and some tradeoffs may be necessary relative to what is feasible in a
higher latency service.  The tradeoffs may include higher costs, or
delivering a lower quality video, or reduced flexibility for adaptive
bitrates, or reduced flexibility for available resolutions so that
fewer devices can receive an encoding tuned for their display.  Low-
latency live delivery is also more susceptible to user-visible
disruptions due to transient network conditions than higher latency
services.
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 a LL-HLS client retrieves each chunk with a separate HTTP GET
request, a 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):
The same techniques used to allow a media player to switch between
renditions of different bitrates at segment or chunk boundaries can
also be used to enable the dynamic insertion of advertisements.
Paragraph (version B):
The same techniques used to allow a media player to switch between
renditions of different bitrates at segment or chunk boundaries can
also be used to enable the dynamic insertion of advertisements
(herafter referred to as "ads").
Paragraph (version A):
A few specific examples of surprising phenomena that affect bitrate
detection measurements are described in the following subsections.
As these examples will demonstrate, it's common to encounter cases
that can deliver application level measurements that are too low, too
high, and (possibly) correct but varying more quickly than a lab-
tested selection algorithm might expect.
Paragraph (version B):
A few specific examples of surprising phenomena that affect bitrate
detection measurements are described in the following subsections.
As these examples will demonstrate, it is common to encounter cases
that can deliver application level measurements that are too low, too
high, and (possibly) correct but varying more quickly than a lab-
tested selection algorithm might expect.
Paragraph (version A):
It's worth noting that more modern transport protocols such as QUIC
have mitigation of head-of-line blocking as a protocol design goal.
See quic-behavior for more details.
Paragraph (version B):
It is worth noting that more modern transport protocols such as QUIC
have mitigation of head-of-line blocking as a protocol design goal.
See quic-behavior for more details.
Paragraph (version A):
It's also worth pointing out that because UDP has no transport-layer
feedback mechanisms, UDP-based applications that send and receive
substantial amounts of information are expected to provide their own
feedback mechanisms.  This expectation is most recently codified in
Best Current Practice RFC8085.
Paragraph (version B):
It is also worth pointing out that because UDP has no transport-layer
feedback mechanisms, UDP-based applications that send and receive
substantial amounts of information are expected to provide their own
feedback mechanisms.  This expectation is most recently codified in
Best Current Practice RFC8085.
Paragraph (version A):
As noted in tcp-behavior, there is increasing interest in transport
protocol behaviors that respond to delay measurements, instead of
responding to packet loss.  These behaviors may deliver improved user
experience, but in some cases have not responded to sustained packet
loss, which exhausts available buffers along the end-to-end path that
may affect other users sharing that path.  The QUIC protocol provides
a set of congestion control hooks that can be used for algorithm
agility, and RFC9002 defines a basic algorithm with transport
behavior that is roughly similar to TCP NewReno RFC6582.  However,
QUIC senders can and do unilaterally choose to use different
algorithms such as loss-based CUBIC RFC8312, delay-based COPA or BBR,
or even something completely different.
Paragraph (version B):
As noted in tcp-behavior, there is an increasing interest in
transport protocol behaviors that respond to delay measurements,
instead of responding to packet loss.  These behaviors may deliver
improved user experience, but in some cases have not responded to
sustained packet loss, which exhausts available buffers along the
end-to-end path that may affect other users sharing that path.  The
QUIC protocol provides a set of congestion control hooks that can be
used for algorithm agility, and RFC9002 defines a basic algorithm
with transport behavior that is roughly similar to TCP NewReno
RFC6582.  However, QUIC senders can and do unilaterally choose to use
different algorithms such as loss-based CUBIC RFC8312, delay-based
COPA or BBR, or even something completely different.
Paragraph (version A):
Media encrypted at the application layer, typically using some
sort of Digital Rights Management (DRM) system, and typically
remaining encrypted "at rest", when senders and receivers store
it,
Paragraph (version B):
Media encrypted at the application layer, typically using some
sort of Digital Rights Management (DRM) system, and typically
remaining encrypted "at rest", when senders and receivers store
it.
Paragraph (version B):
Media encrypted by the sender at the transport layer, and
remaining encrypted until it reaches the ultimate media consumer
(in this document, referred to as "end-to-end media encryption").
Paragraph (version A):
Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran,
Glenn Deen, Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham,
Matt Stock, Mike English, Renan Krishna, Roni Even, and Will Law for
very helpful suggestions, reviews and comments.
Paragraph (version B):
Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran,
Glenn Deen, Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham,
Matt Stock, Mike English, Renan Krishna, Roni Even, Sanjay Mishra,
and Will Law for very helpful suggestions, reviews and comments.