Draft: draft-ietf-mops-streaming-opcons

Commentary: and , I was bored enough today to go thru the entire document a few times to fix as many nits as I could find . Please have a look and then if all good , merge this PR . It will break the existing PRs , apologies for that ( but they are relatively short texts ) . I personally think we can do a few more passes to find more nits and maybe remove some of the remaining quotation marks ( which I think were used more often than I would personally use ) :) 
 I think there 's one " packetloss " ( needs a space ) , and I 'm not sure about putting commas inside closing quotation marks , but you fixed a LOT of nits . I 'll merge this now . 
  go into the quotation marks based on some American grammar rule :) beats me , too . 
 I 'm glad I did n't change that back ! : laughing : 
 From 
 - thank you for this review . You caught a lot more things than I was hoping were still in there . : grinning : 
 PR should address these issues ( and more ) . 
 Agree with that this fixed lots of stuff . I 'd like to leave it open so we can run this tool again after addressing more issues .
Paragraph (version A):
This document provides an overview of operational networking issues
that pertain to quality of experience when streaming video and other
high-bitrate media over the Internet.
Paragraph (version A):
This document examines networking and transport protocol issues as
they relate to quality of experience (QOE) in Internet media
delivery, especially focusing on capturing characteristics of
streaming video delivery that have surprised network designers or
transport experts who lack specific video expertise, since streaming
media highlights key differences between common assumptions in
existing networking practices and observations of video delivery
issues encountered when streaming media over those existing networks.
Paragraph (version B):
This document provides an overview of operational networking issues
that pertain to the quality of experience when streaming video and
other high-bitrate media over the Internet.
Paragraph (version B):
This document examines networking and transport protocol issues as
they relate to the quality of experience (QoE) in Internet media
delivery, especially focusing on capturing characteristics of
streaming video delivery that have surprised network designers or
transport experts who lack specific video expertise, since streaming
media highlights key differences between common assumptions in
existing networking practices and observations of video delivery
issues encountered when streaming media over those existing networks.
Paragraph (version A):
Streaming is transmission of a continuous media from a server to a
client and its simultaneous consumption by the client.
Paragraph (version A):
Here, "continuous media" refers to media and associated streams
such as video, audio, metadata, etc.  In this definition, the
critical term is "simultaneous", as it is not considered streaming
if one downloads a video file and plays it after the download is
completed, which would be called download-and-play.
Paragraph (version A):
First, the server's transmission rate must (loosely or tightly)
match to client's consumption rate in order to provide
uninterrupted playback.  That is, the client must not run out of
data (buffer underrun) or accept more data than it can buffer
before playback (buffer overrun) as any excess media that cannot
be buffered is simply discarded.
Paragraph (version A):
Second, the client's consumption rate is limited not only by
bandwidth availability,but also media availability.  The client
cannot fetch media that is not available from a server yet.
Paragraph (version B):
Streaming is the transmission of continuous media from a server to
a client and its simultaneous consumption by the client.
Paragraph (version B):
Here, "continuous media" refers to media and associated streams
such as video, audio, metadata, etc.  In this definition, the
critical term is "simultaneous," as it is not considered streaming
if one downloads a media file and plays it after the download is
completed, which would be called download-and-play.
Paragraph (version B):
First, the server's transmission rate must (loosely or tightly)
match the client's consumption rate to provide uninterrupted
playback.  That is, the client must not run out of data (buffer
underrun) or accept more data than it can buffer before playback
(buffer overrun), as any excess media that cannot be buffered is
simply discarded.
Paragraph (version B):
Second, the client's consumption rate is limited by not only
bandwidth availability but also media availability.  The client
cannot fetch media that is not available from a server yet.
Paragraph (version A):
A description of existing transport protocols used for video
streaming, and the issues encountered when using those protocols,
along with a description of the QUIC transport protocol RFC9000
that we expect to be used for streaming media (sec-trans),
Paragraph (version A):
A number of useful pointers for further reading on this rapidly
changing subject (further).
Paragraph (version A):
Making specific recommendations on operational practices aimed at
mitigating the issues described in this document is out of scope,
though some existing mitigations are mentioned in passing.  The
intent is to provide a point of reference for future solution
proposals to use in describing how new technologies address or avoid
existing observed problems.
Paragraph (version B):
A description of existing transport protocols used for video
streaming and the issues encountered when using those protocols,
along with a description of the QUIC transport protocol RFC9000
that we expect to be used for streaming media (sec-trans),
Paragraph (version B):
Several pointers for further reading on this rapidly changing
subject (further).
Paragraph (version B):
Making specific recommendations on operational practices to mitigate
the issues described in this document is out of scope, though some
existing mitigations are mentioned in passing.  The intent is to
provide a point of reference for future solution proposals to
describe how new technologies address or avoid existing problems.
Paragraph (version A):
As the internet has grown, an increasingly large share of the traffic
delivered to end users has become video.  The most recent available
estimates found that 75% of the total traffic to end users was video
in 2019.  At that time, the share of traffic that was video had been
growing for years and was projected to continue growing (Appendix D
of CVNI).
Paragraph (version A):
A substantial part of this growth is due to increased use of
streaming video, although the amount of video traffic in real-time
communications (for example, online videoconferencing) has also grown
significantly.  While both streaming video and videoconferencing have
real-time delivery and latency requirements, these requirements vary
from one application to another.  For additional discussion of
latency requirements, see latency-cons.
Paragraph (version B):
As the Internet has grown, an increasingly large share of the traffic
delivered to end users has become video.  The most recent available
estimates found that 75% of the total traffic to end users was video
in 2019.  At that time, the share of video traffic had been growing
for years and was projected to continue growing (Appendix D of CVNI).
Paragraph (version B):
A substantial part of this growth is due to the increased use of
streaming video.  However, video traffic in real-time communications
(for example, online videoconferencing) has also grown significantly.
While both streaming video and videoconferencing have real-time
delivery and latency requirements, these requirements vary from one
application to another.  For additional discussion of latency
requirements, see latency-cons.
Paragraph (version A):
HTTP can make use of already-deployed caching infrastructure such
as CDNs (Content Delivery Networks), local proxies, and browser
caches.
Paragraph (version B):
HTTP can use already-deployed caching infrastructure such as
content delivery networks (CDN), local proxies, and browser
caches.
Paragraph (version A):
Unreliable media delivery using RTP and other UDP-based protocols is
also discussed in ultralow, 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 B):
Unreliable media delivery using RTP and other UDP-based protocols is
also discussed in ultralow, udp-behavior, and hop-by-hop-encrypt, but
it is difficult to give general guidance for these applications.  For
instance, when packet loss occurs, the most appropriate response may
depend on the type of codec being used.
Paragraph (version A):
Video bitrate selection depends on many variables including the
resolution (height and width), frame rate, color depth, codec,
encoding parameters, scene complexity and amount of motion.
Generally speaking, as the resolution, frame rate, color depth, scene
complexity and amount of motion increase, the encoding bitrate
increases.  As newer codecs with better compression tools are used,
the encoding bitrate decreases.  Similarly, a multi-pass encoding
generally produces better quality output compared to single-pass
encoding at the same bitrate, or delivers the same quality at a lower
bitrate.
Paragraph (version B):
Video bitrate selection depends on many variables including the
resolution (height and width), frame rate, color depth, codec,
encoding parameters, scene complexity and amount of motion.
Generally speaking, as the resolution, frame rate, color depth, scene
complexity and amount of motion increase, the encoding bitrate
increases.  As newer codecs with better compression tools are used,
the encoding bitrate decreases.  Similarly, a multi-pass encoding
generally produces better quality output compared to single-pass
encoding at the same bitrate or delivers the same quality at a lower
bitrate.
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 A):
Even basic virtual reality (360-degree) videos that allow users to
look around freely (referred to as "three degrees of freedom", or
3DoF) require substantially larger bitrates when they are captured
and encoded as such videos require multiple fields of view of the
scene.  Yet, due to smart delivery methods such as viewport-based or
tiled-based streaming, we do not need to send the whole scene to the
user.  Instead, the user needs only the portion corresponding to its
viewpoint at any given time (Survey360o).
Paragraph (version A):
In more immersive applications, where limited user movement ("three
degrees of freedom plus", or 3DoF+) or full user movement ("six
degrees of freedom", or 6DoF) is allowed, the required bitrate grows
even further.  In this case, immersive content is typically referred
to as volumetric media.  One way to represent the volumetric media is
to use point clouds, where streaming a single object may easily
require a bitrate of 30 Mbps or higher.  Refer to MPEGI and PCC for
more details.
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 B):
Even basic virtual reality (360-degree) videos that allow users to
look around freely (referred to as "three degrees of freedom" or
3DoF) require substantially larger bitrates when they are captured
and encoded as such videos require multiple fields of view of the
scene.  Yet, due to smart delivery methods such as viewport-based or
tile-based streaming, we do not need to send the whole scene to the
user.  Instead, the user needs only the portion corresponding to its
viewpoint at any given time (Survey360o).
Paragraph (version B):
In more immersive applications, where limited user movement ("three
degrees of freedom plus" or 3DoF+) or full user movement ("six
degrees of freedom" or 6DoF) is allowed, the required bitrate grows
even further.  In this case, immersive content is typically referred
to as volumetric media.  One way to represent the volumetric media is
to use point clouds, where streaming a single object may easily
require a bitrate of 30 Mbps or higher.  Refer to MPEGI and PCC for
more details.
Paragraph (version A):
Media servers often respond to application-level feedback from the
media player that indicates a bottleneck somewhere along the path,
by adjusting the amount of media that the media server will send
to the media player in a given timeframe.  This is described in
greater detail in sec-abr.
Paragraph (version A):
Media servers also typically rely on transport protocols with
capacity-seeking congestion controllers that probe for bandwidth,
and adjust the sending rate based on transport mechanisms.  This
is described in greater detail in sec-trans.
Paragraph (version A):
One might wonder why media servers and transport protocols are each
blissfully ignorant of what the other is doing, and there are
multiple reasons for that, but one reason is that media servers may
be implemented to run under a general-purpose operating system which
typically has its transport protocols implemented in the operating
system kernel, making decisions that the media server never knows
about.
Paragraph (version A):
the transport protocol detects loss due to congestion, and reduces
its sending window size per round trip,
Paragraph (version A):
the media server adapts to application-level feedback from the
media player, and reduces its own sending rate,
Paragraph (version A):
the transport protocol can't probe for available path bandwidth by
sending at a higher rate.
Paragraph (version A):
In order to avoid these types of situations, which can potentially
affect all the users whose streaming media traverses a bottleneck,
there are several possible mitigations that streaming operators can
use, but the first step toward mitigating a problem is knowing when
that problem occurs.
Paragraph (version B):
Media servers often respond to application-level feedback from the
media player that indicates a bottleneck somewhere along the path
by adjusting the amount of media that the media server will send
to the media player in a given timeframe.  This is described in
greater detail in sec-abr.
Paragraph (version B):
Media servers also typically rely on transport protocols with
capacity-seeking congestion controllers that probe for bandwidth
and adjust the sending rate based on transport mechanisms.  This
is described in greater detail in sec-trans.
Paragraph (version B):
One might wonder why media servers and transport protocols are each
blissfully ignorant of what the other is doing, and there are
multiple reasons for that.  However, one reason is that media servers
may be implemented to run under a general-purpose operating system
that typically has its transport protocols implemented in the
operating system kernel, making decisions that the media server never
knows about.
Paragraph (version B):
the transport protocol detects loss due to congestion and reduces
its sending window size per round trip,
Paragraph (version B):
the media server adapts to application-level feedback from the
media player and reduces its own sending rate,
Paragraph (version B):
the transport protocol cannot probe for available path bandwidth
by sending at a higher rate.
Paragraph (version B):
To avoid these types of situations, which can potentially affect all
the users whose streaming media traverses a bottleneck, there are
several possible mitigations that streaming operators can use.
However, the first step toward mitigating a problem is knowing when
that problem occurs.
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):
In order 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 tcp-
behavior for more information.
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, itself, respond to
indications of path congestion.
Paragraph (version B):
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 tcp-behavior for
more information.
Paragraph (version A):
focusing on end-point monitoring and reporting, rather than on
passive monitoring.
Paragraph (version B):
focusing on endpoint monitoring and reporting, rather than on passive
monitoring.
Paragraph (version A):
The bitrate requirements in scaling are per end-user actively
consuming a media feed, so in the worst case, the bitrate demands can
be multiplied by the number of simultaneous users to find the
bandwidth requirements for a delivery path with that number of users
downstream.  For example, at a node with 10,000 downstream users
simultaneously consuming video streams, approximately 80 Gbps might
be necessary in order for all of them to get typical content at 1080p
resolution.
Paragraph (version A):
However, when there is some overlap in the feeds being consumed by
end users, it is sometimes possible to reduce the bandwidth
provisioning requirements for the network by performing some kind of
replication within the network.  This can be achieved via object
caching with delivery of replicated objects over individual
connections, and/or by packet-level replication using multicast.
Paragraph (version B):
The bitrate requirements in scaling are per end user actively
consuming a media feed, so in the worst case, the bitrate demands can
be multiplied by the number of simultaneous users to find the
bandwidth requirements for a delivery path with that number of users
downstream.  For example, at a node with 10,000 downstream users
simultaneously consuming video streams, approximately 80 Gbps might
be necessary for all of them to get typical content at 1080p
resolution.
Paragraph (version B):
However, when there is some overlap in the feeds being consumed by
end users, it is sometimes possible to reduce the bandwidth
provisioning requirements for the network by performing some kind of
replication within the network.  This can be achieved via object
caching with the delivery of replicated objects over individual
connections and/or by packet-level replication using multicast.
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 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 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 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):
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 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 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):
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 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 video, 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 that 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 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, and complaints to regulators calling for regulatory
action.
Paragraph (version A):
The BitTorrent case study is just one example, but 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 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):
The causes of unpredictable usage described in sec-unpredict were
more or less the result of human choices, but 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 B):
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 B):
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 B):
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 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 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 B):
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 B):
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 B):
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):
The increase in daytime bandwidth consumption reflected both
significant increases in "essential" applications such as
videoconferencing and virtual private networks (VPN), and
entertainment applications as people watched videos or played
games.
Paragraph (version B):
The increase in daytime bandwidth consumption reflected both
significant increases in essential applications such as
videoconferencing and virtual private networks (VPN), and
entertainment applications as people watched videos or played
games.
Paragraph (version A):
Streaming media latency refers to the "glass-to-glass" time duration,
which is the delay between the real-life occurrence of an event and
the streamed media being appropriately displayed on an end user's
device.  Note that this is different from the network latency
(defined as the time for a packet to cross a network from one end to
another end) because it includes video encoding/decoding and
buffering time, and for most cases also ingest to an intermediate
service such as a CDN or other video distribution service, rather
than a direct connection to an end user.
Paragraph (version B):
Streaming media latency refers to the "glass-to-glass" time duration,
which is the delay between the real-life occurrence of an event and
the streamed media being appropriately displayed on an end user's
device.  Note that this is different from the network latency
(defined as the time for a packet to cross a network from one end to
another end) because it includes video encoding/decoding and
buffering time, and for most cases also the ingest to an intermediate
service such as a CDN or other video distribution service, rather
than a direct connection to an end user.
Paragraph (version A):
Ultra low-latency delivery of media is defined here as having a
glass-to-glass delay target under one second.
Paragraph (version B):
Ultra-low-latency delivery of media is defined here as having a
glass-to-glass delay target under one second.
Paragraph (version A):
Applications requiring ultra low latency for media delivery are
usually tightly constrained on the available choices for media
transport technologies, and sometimes may need to operate in
controlled environments to reliably achieve their latency and quality
goals.
Paragraph (version B):
Applications requiring ultra-low latency for media delivery are
usually tightly constrained on the available choices for media
transport technologies and sometimes may need to operate in
controlled environments to reliably achieve their latency and quality
goals.
Paragraph (version A):
Worth noting is that many applications for ultra low-latency delivery
do not need to scale to more than a few users at a time, which
simplifies many delivery considerations relative to other use cases.
Paragraph (version B):
Worth noting is that many applications for ultra-low-latency delivery
do not need to scale to more than a few users at a time, which
simplifies many delivery considerations relative to other use cases.
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 game
play, 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):
This level of latency is targeted to have a user experience similar
to traditional broadcast TV delivery.  A frequently cited problem
with failing to achieve this level of latency for live sporting
events is the user experience failure from having crowds within
earshot of one another who react audibly to an important play, or
from users who learn of an event in the match via some other channel,
for example social media, before it has happened on the screen
showing the sporting event.
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 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 B):
This level of latency is targeted to have a user experience similar
to traditional broadcast TV delivery.  A frequently cited problem
with failing to achieve this level of latency for live sporting
events is the user experience failure from having crowds within
earshot of one another who react audibly to an important play, or
from users who learn of an event in the match via some other channel,
for example, social media, before it has happened on the screen
showing the sporting event.
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,
delivering a lower quality video, 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):
Implementation of a low-latency live video service can be achieved
with the use of low-latency extensions of HLS (called LL-HLS) I-
D.draft-pantos-hls-rfc8216bis and DASH (called LL-DASH) LL-DASH.
These extensions use the Common Media Application Format (CMAF)
standard MPEG-CMAF that allows the media to be packaged into and
transmitted in units smaller than segments, which are called chunks
in CMAF language.  This way, the latency can be decoupled from the
duration of the media segments.  Without a CMAF-like packaging, lower
latencies can only be achieved by using very short segment durations.
However, shorter segments means more frequent intra-coded frames and
that is detrimental to video encoding quality.  CMAF allows us to
still use longer segments (improving encoding quality) without
penalizing latency.
Paragraph (version A):
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 B):
Implementation of a low-latency live video service can be achieved
with the use of low-latency extensions of HLS (called LL-HLS) I-
D.draft-pantos-hls-rfc8216bis and DASH (called LL-DASH) LL-DASH.
These extensions use the Common Media Application Format (CMAF)
standard MPEG-CMAF that allows the media to be packaged into and
transmitted in units smaller than segments, which are called chunks
in CMAF language.  This way, the latency can be decoupled from the
duration of the media segments.  Without a CMAF-like packaging, lower
latencies can only be achieved by using very short segment durations.
However, using shorter segments means using more frequent intra-coded
frames and that is detrimental to video encoding quality.  CMAF
allows us to still use longer segments (improving encoding quality)
without penalizing latency.
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 level of latency can typically be achieved at scale with
commodity CDN services for HTTP(s) delivery, and in some cases the
increased time window can allow for production of a wider range of
encoding options relative to the requirements for a lower latency
service without the need for increasing the hardware footprint, which
can allow for wider device interoperability.
Paragraph (version A):
On-Demand media streaming refers to playback of pre-recorded media
based on a user's action.  In some cases on-demand media is produced
as a by-product of a live media production, using the same segments
as the live event, but freezing the manifest after the live event has
finished.  In other cases, on-demand media is constructed out of pre-
recorded assets with no streaming necessarily involved during the
production of the on-demand content.
Paragraph (version B):
This level of latency can typically be achieved at scale with
commodity CDN services for HTTP(s) delivery, and in some cases, the
increased time window can allow for the production of a wider range
of encoding options relative to the requirements for a lower latency
service without the need for increasing the hardware footprint, which
can allow for wider device interoperability.
Paragraph (version B):
On-demand media streaming refers to the playback of pre-recorded
media based on a user's action.  In some cases, on-demand media is
produced as a by-product of a live media production, using the same
segments as the live event, but freezing the manifest after the live
event has finished.  In other cases, on-demand media is constructed
out of pre-recorded assets with no streaming necessarily involved
during the production of the on-demand content.
Paragraph (version A):
A simple model of video playback can be described as a video stream
consumer, a buffer, and a transport mechanism that fills the buffer.
The consumption rate is fairly static and is represented by the
content bitrate.  The size of the buffer is also commonly a fixed
size.  The fill process needs to be at least fast enough to ensure
that the buffer is never empty, however it also can have significant
complexity when things like personalization or ad workflows are
introduced.
Paragraph (version B):
A simple model of video playback can be described as a video stream
consumer, a buffer, and a transport mechanism that fills the buffer.
The consumption rate is fairly static and is represented by the
content bitrate.  The size of the buffer is also commonly a fixed
size.  The fill process needs to be at least fast enough to ensure
that the buffer is never empty, however, it also can have significant
complexity when things like personalization or ad workflows are
introduced.
Paragraph (version A):
Media servers can provide media streams at various bitrates because
the media has been encoded at various bitrates.  This is a so-called
"ladder" of bitrates, that can be offered to media players as part of
the manifest that describes the media being requested by the media
player, so that the media player can select among the available
bitrate choices.
Paragraph (version B):
Media servers can provide media streams at various bitrates because
the media has been encoded at various bitrates.  This is a so-called
"ladder" of bitrates that can be offered to media players as part of
the manifest that describes the media being requested by the media
player, so that the media player can select among the available
bitrate choices.
Paragraph (version A):
Many systems will do an initial probe or a very simple throughput
speed test at the start of a video playback.  This is done to get a
rough sense of the highest video bitrate in the ABR ladder that the
network between the server and player will likely be able to provide
under initial network conditions.  After the initial testing, clients
tend to rely upon passive network observations and will make use of
player side statistics such as buffer fill rates to monitor and
respond to changing network conditions.
Paragraph (version B):
Many systems will do an initial probe or a very simple throughput
speed test at the start of video playback.  This is done to get a
rough sense of the highest video bitrate in the ABR ladder that the
network between the server and player will likely be able to provide
under initial network conditions.  After the initial testing, clients
tend to rely upon passive network observations and will make use of
player side statistics such as buffer fill rates to monitor and
respond to changing network conditions.
Paragraph (version A):
The choice of bitrate occurs within the context of optimizing for one
or more metrics monitored by the client, such as highest achievable
video quality or lowest chances for a rebuffering event (playback
stall).
Paragraph (version B):
The choice of bitrate occurs within the context of optimizing for one
or more metrics monitored by the client, such as the highest
achievable video quality or lowest chances for a rebuffering event
(playback stall).
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
(herafter referred to as "ads").
Paragraph (version A):
Ads may be inserted either with Client Side Ad Insertion (CSAI) or
Server Side Ad Insertion (SSAI).  In CSAI, the ABR manifest will
generally include links to an external ad server for some segments of
the media stream, while in SSAI the server will remain the same
during advertisements, but will include media segments that contain
the advertising.  In SSAI, the media segments may or may not be
sourced from an external ad server like with CSAI.
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
(hereafter referred to as "ads").
Paragraph (version B):
Ads may be inserted either with Client-side Ad Insertion (CSAI) or
Server-side Ad Insertion (SSAI).  In CSAI, the ABR manifest will
generally include links to an external ad server for some segments of
the media stream, while in SSAI the server will remain the same
during advertisements, but will include media segments that contain
the advertising.  In SSAI, the media segments may or may not be
sourced from an external ad server like with CSAI.
Paragraph (version A):
In general, the more targeted the ad request is, the more requests
the ad service needs to be able to handle concurrently.  If
connectivity is poor to the ad service, this can cause rebuffering
even if the underlying video assets (both content and ads) are able
to be accessed quickly.  The less targeted, the more likely the ad
requests can be consolidated and can leverage the same caching
techniques as the video content.
Paragraph (version A):
In some cases, especially with SSAI, advertising space in a stream is
reserved for a specific advertiser and can be integrated with the
video so that the segments share the same encoding properties such as
bitrate, dynamic range, and resolution.  However, in many cases ad
servers integrate with a Supply Side Platform (SSP) that offers
advertising space in real-time auctions via an Ad Exchange, with bids
for the advertising space coming from Demand Side Platforms (DSPs)
that collect money from advertisers for delivering the
advertisements.  Most such Ad Exchanges use application-level
protocol specifications published by the Interactive Advertising
Bureau IAB-ADS, an industry trade organization.
Paragraph (version B):
In general, the more targeted the ad request is, the more requests
the ad service needs to be able to handle concurrently.  If
connectivity is poor to the ad service, this can cause rebuffering
even if the underlying video assets (both content and ads) can be
accessed quickly.  The less targeted, the more likely the ad requests
can be consolidated and can leverage the same caching techniques as
the video content.
Paragraph (version B):
In some cases, especially with SSAI, advertising space in a stream is
reserved for a specific advertiser and can be integrated with the
video so that the segments share the same encoding properties such as
bitrate, dynamic range, and resolution.  However, in many cases, ad
servers integrate with a Supply Side Platform (SSP) that offers
advertising space in real-time auctions via an Ad Exchange, with bids
for the advertising space coming from Demand Side Platforms (DSPs)
that collect money from advertisers for delivering the
advertisements.  Most such Ad Exchanges use application-level
protocol specifications published by the Interactive Advertising
Bureau IAB-ADS, an industry trade organization.
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, either of which can
sometimes 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, either of which can
sometimes 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):
In general this is a rapidly developing space with many
considerations, and media streaming operators engaged in advertising
may need to research these and other concerns to find solutions that
meet their user experience, user privacy, and financial goals.  For
further reading on mitigations, BAP has published some standards and
best practices based on user experience research.
Paragraph (version B):
In general, this is a rapidly developing space with many
considerations, and media streaming operators engaged in advertising
may need to research these and other concerns to find solutions that
meet their user experience, user privacy, and financial goals.  For
further reading on mitigations, BAP has published some standards and
best practices based on user experience research.
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 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 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):
TCP slow-start when restarting after idle requires multiple RTTs
to re-establish a throughput at the network's available capacity.
When the active transmission time for segments is substantially
shorter than the time between segments, leaving an idle gap
between segments that triggers a restart of TCP slow-start, the
estimate of the successful download speed coming from the
application-visible receive rate on the socket can thus end up
much lower than the actual available network capacity.  This in
turn can prevent a shift to the most appropriate bitrate.  RFC7661
provides some mitigations for this effect at the TCP transport
layer, for senders who anticipate a high incidence of this
problem.
Paragraph (version B):
TCP slow-start when restarting after idle requires multiple RTTs
to re-establish a throughput at the network's available capacity.
When the active transmission time for segments is substantially
shorter than the time between segments, leaving an idle gap
between segments that triggers a restart of TCP slow-start, the
estimate of the successful download speed coming from the
application-visible receive rate on the socket can thus end up
much lower than the actual available network capacity.  This, in
turn, can prevent a shift to the most appropriate bitrate.
RFC7661 provides some mitigations for this effect at the TCP
transport layer for senders who anticipate a high incidence of
this problem.
Paragraph (version A):
Another way to mitigate this effect is by the help of two
simultaneous TCP connections, as explained in MMSys11 for Microsoft
Smooth Streaming.  In some cases, the system-level TCP slow-start
restart can also be disabled, for example as described in OReilly-
HPBN.
Paragraph (version B):
Another way to mitigate this effect is by the help of two
simultaneous TCP connections, as explained in MMSys11 for Microsoft
Smooth Streaming.  In some cases, the system-level TCP slow-start
restart can also be disabled, for example, as described in OReilly-
HPBN.
Paragraph (version A):
In the event of a lost packet on a TCP connection with SACK support
(a common case for segmented delivery in practice), loss of a packet
can provide a confusing bandwidth signal to the receiving
application.  Because of the sliding window in TCP, many packets may
be accepted by the receiver without being available to the
application until the missing packet arrives.  Upon arrival of the
one missing packet after retransmit, the receiver will suddenly get
access to a lot of data at the same time.
Paragraph (version B):
In the event of a lost packet on a TCP connection with SACK support
(a common case for segmented delivery in practice), loss of a packet
can provide a confusing bandwidth signal to the receiving
application.  Because of the sliding window in TCP, many packets may
be accepted by the receiver without being available to the
application until the missing packet arrives.  Upon the arrival of
the one missing packet after retransmit, the receiver will suddenly
get access to a lot of data at the same time.
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 detction have
emerged from radio interference and signal strength effects.
Paragraph (version B):
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):
To that effect, the Consumer Technology Association (CTA) who owns
the Web Application Video Ecosystem (WAVE) project has published two
important specifications.
Paragraph (version A):
CTA-2066 specifies a set of media player events, properties, QOE
metrics and associated terminology for representing streaming media
QOE across systems, media players and analytics vendors.  While all
these events, properties, metrics and associated terminology is used
across a number of proprietary analytics and measurement solutions,
they were used in slightly (or vastly) different ways that led to
interoperability issues.  CTA-2066 attempts to address this issue by
defining a common terminology as well as how each metric should be
computed for consistent reporting.
Paragraph (version B):
To that effect, the Consumer Technology Association (CTA), who owns
the Web Application Video Ecosystem (WAVE) project, has published two
important specifications.
Paragraph (version B):
CTA-2066 specifies a set of media player events, properties, QoE
metrics and associated terminology for representing streaming media
QoE across systems, media players and analytics vendors.  While all
these events, properties, metrics and associated terminology are used
across a number of proprietary analytics and measurement solutions,
they were used in slightly (or vastly) different ways that led to
interoperability issues.  CTA-2066 attempts to address this issue by
defining a common terminology as well as how each metric should be
computed for consistent reporting.
Paragraph (version A):
For most of the history of the Internet, we have trusted UDP-based
applications to limit their impact on other users.  One of the
strategies used was to use UDP for simple query-response application
protocols, such as DNS, which is often used to send a single-packet
request to look up the IP address for a DNS name, and return a
single-packet response containing the IP address.  Although it is
possible to saturate a path between a DNS client and DNS server with
DNS requests, in practice, that was rare enough that DNS included few
mechanisms to resolve contention between DNS users and other users
(whether they are also using DNS, or using other application
protocols that share the same pathways).
Paragraph (version B):
For most of the history of the Internet, we have trusted UDP-based
applications to limit their impact on other users.  One of the
strategies used was to use UDP for simple query-response application
protocols, such as DNS, which is often used to send a single-packet
request to look up the IP address for a domain name, and return a
single-packet response containing the IP address.  Although it is
possible to saturate a path between a DNS client and DNS server with
DNS requests, in practice, that was rare enough that DNS included few
mechanisms to resolve contention between DNS users and other users
(whether they are also using DNS, or using other application
protocols that share the same pathways).
Paragraph (version A):
In recent times, the usage of UDP-based applications that were not
simple query-response protocols has grown substantially, and since
UDP does not provide any feedback mechanism to senders to help limit
impacts on other users, application-level protocols such as RTP
RFC3550 have been responsible for the decisions that TCP-based
applications have delegated to TCP - what to send, how much to send,
and when to send it.  Because UDP itself 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, and to respond to the feedback the application
receives.  This expectation is most recently codified in Best Current
Practice RFC8085.
Paragraph (version B):
In recent times, the usage of UDP-based applications that were not
simple query-response protocols has grown substantially, and since
UDP does not provide any feedback mechanism to senders to help limit
impacts on other users, application-level protocols such as RTP
RFC3550 have been responsible for the decisions that TCP-based
applications have delegated to TCP - what to send, how much to send,
and when to send it.  Because UDP itself 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 and respond to the feedback the application
receives.  This expectation is most recently codified in Best Current
Practice RFC8085.
Paragraph (version A):
RTP RFC3550, which can notice loss and repair some limited
reordering,
Paragraph (version B):
RTP RFC3550, which can notice packetloss and repair some limited
reordering,
Paragraph (version A):
Under congestion and loss, approaches like the above generally
experiences transient video artifacts more often and delay of
playback effects less often, as compared with reliable segment
transport.  Often one of the key goals of using a UDP-based transport
that allows some unreliability is to reduce latency and better
support applications like videoconferencing, or for other live-action
video with interactive components, such as some sporting events.
Paragraph (version A):
Congestion avoidance strategies for deployments using unreliable
transport protocols vary widely in practice, ranging from being
entirely unresponsive to congestion, to using feedback signaling to
change encoder settings (as in RFC5762), to using fewer enhancement
layers (as in RFC6190), to using proprietary methods to detect QOE
issues and turn off video in order to allow less bandwidth-intensive
media such as audio to be delivered.
Paragraph (version B):
Under congestion and loss, approaches like the above generally
experience transient video artifacts more often and delay of playback
effects less often, as compared with reliable segment transport.
Often one of the key goals of using a UDP-based transport that allows
some unreliability is to reduce latency and better support
applications like videoconferencing, or for other live-action video
with interactive components, such as some sporting events.
Paragraph (version B):
Congestion avoidance strategies for deployments using unreliable
transport protocols vary widely in practice, ranging from being
entirely unresponsive to congestion, to using feedback signaling to
change encoder settings (as in RFC5762), to using fewer enhancement
layers (as in RFC6190), to using proprietary methods to detect QoE
issues and turn off video to allow less bandwidth-intensive media
such as audio to be delivered.
Paragraph (version A):
The notion of "Circuit Breakers" has also been applied to other UDP
applications in RFC8084, such as tunneling packets over UDP that are
potentially not congestion-controlled (for example, "Encapsulating
MPLS in UDP", as described in RFC7510).  If streaming media is
carried in tunnels encapsulated in UDP, these media streams may
encounter "tripped circuit breakers", with resulting user-visible
impacts.
Paragraph (version B):
The notion of "Circuit Breakers" has also been applied to other UDP
applications in RFC8084, such as tunneling packets over UDP that are
potentially not congestion-controlled (for example, "Encapsulating
MPLS in UDP," as described in RFC7510).  If streaming media is
carried in tunnels encapsulated in UDP, these media streams may
encounter "tripped circuit breakers," with resulting user-visible
impacts.
Paragraph (version A):
For most of the history of the Internet, we have trusted TCP to limit
the impact of applications that sent a significant number of packets,
in either or both directions, on other users.  Although early
versions of TCP were not particularly good at limiting this impact
RFC0793, the addition of Slow Start and Congestion Avoidance, as
described in RFC2001, were critical in allowing TCP-based
applications to "use as much bandwidth as possible, but to avoid
using more bandwidth than was possible".  Although dozens of RFCs
have been written refining TCP decisions about what to send, how much
to send, and when to send it, since 1988 Jacobson-Karels the signals
available for TCP senders remained unchanged - end-to-end
acknowledgements for packets that were successfully sent and
received, and packet timeouts for packets that were not.
Paragraph (version B):
For most of the history of the Internet, we have trusted TCP to limit
the impact of applications that sent a significant number of packets,
in either or both directions, on other users.  Although early
versions of TCP were not particularly good at limiting this impact
RFC0793, the addition of Slow Start and Congestion Avoidance, as
described in RFC2001, were critical in allowing TCP-based
applications to use as much bandwidth as possible, but to avoid using
more bandwidth than was possible.  Although dozens of RFCs have been
written refining TCP decisions about what to send, how much to send,
and when to send it, since 1988 Jacobson-Karels the signals available
for TCP senders remained unchanged - end-to-end acknowledgements for
packets that were successfully sent and received, and packet timeouts
for packets that were not.
Paragraph (version A):
In recent times, the TCP goal of probing for available bandwidth, and
"backing off" when a network path is saturated, has been supplanted
by the goal of avoiding growing queues along network paths, which
prevent TCP senders from reacting quickly when a network path is
saturated.  Congestion control mechanisms such as COPA COPA18 and BBR
I-D.cardwell-iccrg-bbr-congestion-control make these decisions based
on measured path delays, assuming that if the measured path delay is
increasing, the sender is injecting packets onto the network path
faster than the receiver can accept them, so the sender should adjust
its sending rate accordingly.
Paragraph (version B):
In recent times, the TCP goal of probing for available bandwidth and
"backing off" when a network path is saturated has been supplanted by
the goal of avoiding growing queues along network paths, which
prevent TCP senders from reacting quickly when a network path is
saturated.  Congestion control mechanisms such as COPA COPA18 and BBR
I-D.cardwell-iccrg-bbr-congestion-control make these decisions based
on measured path delays, assuming that if the measured path delay is
increasing, the sender is injecting packets onto the network path
faster than the receiver can accept them, so the sender should adjust
its sending rate accordingly.
Paragraph (version A):
As noted in hol-blocking, because TCP provides a reliable, in-order
delivery service for applications, any packet loss for a TCP
connection causes "head-of-line blocking", so that no TCP segments
arriving after a packet is lost will be delivered to the receiving
application until the lost packet is retransmitted, allowing in-order
delivery to the application to continue.  As described in RFC9000,
QUIC connections can carry multiple streams, and when packet losses
do occur, only the streams carried in the lost packet are delayed.
Paragraph (version B):
As noted in hol-blocking, because TCP provides a reliable, in-order
delivery service for applications, any packet loss for a TCP
connection causes head-of-line blocking, so that no TCP segments
arriving after a packet is lost will be delivered to the receiving
application until retransmission of the lost packet has been
received, allowing in-order delivery to the application to continue.
As described in RFC9000, QUIC connections can carry multiple streams,
and when packet losses do occur, only the streams carried in the lost
packet are delayed.
Paragraph (version A):
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):
The Internet community does have experience with deploying new
congestion controllers without melting the Internet.  As noted in
RFC8312, both the CUBIC congestion controller and its predecessor BIC
have significantly different behavior from Reno-style congestion
controllers such as TCP NewReno RFC6582, but both CUBIC and BIC were
added to the Linux kernel in order to allow experimentation and
analysis, and both were then selected as the default TCP congestion
controllers in Linux, and both were deployed globally.
Paragraph (version A):
The point mentioned in tcp-behavior about TCP congestion controllers
being implemented in operating system kernels is different with QUIC.
Although QUIC can be implemented in operating system kernels, one of
the design goals when this work was chartered was "QUIC is expected
to support rapid, distributed development and testing of features",
and to meet this expectation, many implementers have chosen to
implement QUIC in user space, outside the operating system kernel,
and to even distribute QUIC libraries with their own applications.
It is worth noting that streaming operators using HTTP/3, carried
over QUIC, can expect more frequent deployment of new congestion
controller behavior than has been the case with HTTP/1 and HTTP/2,
carried over TCP.
Paragraph (version B):
As noted in tcp-behavior, there is an increasing interest in
congestion control algorithms that respond to delay measurements,
instead of responding to packet loss.  These algorithms may deliver
an 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 congestion
control algorithm 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):
The Internet community does have experience with deploying new
congestion controllers without melting the Internet.  As noted in
RFC8312, both the CUBIC congestion controller and its predecessor BIC
have significantly different behavior from Reno-style congestion
controllers such as TCP NewReno RFC6582, but both CUBIC and BIC were
added to the Linux kernel to allow experimentation and analysis, and
both were then selected as the default TCP congestion controllers in
Linux, and both were deployed globally.
Paragraph (version B):
The point mentioned in tcp-behavior about TCP congestion controllers
being implemented in operating system kernels is different with QUIC.
Although QUIC can be implemented in operating system kernels, one of
the design goals when this work was chartered was "QUIC is expected
to support rapid, distributed development and testing of features,"
and to meet this expectation, many implementers have chosen to
implement QUIC in user space, outside the operating system kernel,
and to even distribute QUIC libraries with their own applications.
It is worth noting that streaming operators using HTTP/3, carried
over QUIC, can expect more frequent deployment of new congestion
controller behavior than has been the case with HTTP/1 and HTTP/2,
carried over TCP.
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 A):
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 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):
Media encrypted by the sender at the transport layer, and
remaining encrypted until it reaches some intermediary that is
_not_ the ultimate media consumer, but has credentials allowing
decryption of the media content.  This intermediary may examine
and even transform the media content in some way, before
forwarding re-encrypted media content (in this document referred
to as "hop-by-hop media encryption").
Paragraph (version A):
In this document, we will focus on media encrypted at the transport
layer, whether encrypted "hop-by-hop" or "end-to-end".  Because media
encrypted at the application layer will only be processed by
application-level entities, this encryption does not have transport-
layer implications.  Of course, both "hop-by-hop" and "end-to-end"
encrypted transport may carry media that is, in addition, encrypted
at the application layer.
Paragraph (version B):
Media encrypted by the sender at the transport layer, and
remaining encrypted until it reaches some intermediary that is
_not_ the ultimate media consumer, but has credentials allowing
decryption of the media content.  This intermediary may examine
and even transform the media content in some way, before
forwarding re-encrypted media content (in this document referred
to as hop-by-hop media encryption).
Paragraph (version B):
In this document, we will focus on media encrypted at the transport
layer, whether encrypted hop-by-hop or end-to-end.  Because media
encrypted at the application layer will only be processed by
application-level entities, this encryption does not have transport-
layer implications.  Of course, both hop-by-hop and end-to-end
encrypted transport may carry media that is, in addition, encrypted
at the application layer.
Paragraph (version A):
Both "end-to-end" and "hop-by-hop" media encryption have specific
implications for streaming operators.  These are described in hop-by-
hop-encrypt and e2em-encrypt.
Paragraph (version B):
Both end-to-end and hop-by-hop media encryption have specific
implications for streaming operators.  These are described in hop-by-
hop-encrypt and e2em-encrypt.
Paragraph (version A):
Because HTTPS has historically layered HTTP on top of TLS, which is
in turn layered on top of TCP, intermediaries do have access to
unencrypted TCP-level transport information, such as retransmissions,
and some carriers exploited this information in attempts to improve
transport-layer performance RFC3135.  The most recent standardized
version of HTTPS, HTTP/3 I-D.ietf-quic-http, uses the QUIC protocol
RFC9000 as its transport layer.  QUIC relies on the TLS 1.3 initial
handshake RFC8446 only for key exchange RFC9001, and encrypts almost
all transport parameters itself, with the exception of a few
invariant header fields.  In the QUIC short header, the only
transport-level parameter which is sent "in the clear" is the
Destination Connection ID RFC8999, and even in the QUIC long header,
the only transport-level parameters sent "in the clear" are the
Version, Destination Connection ID, and Source Connection ID.  For
these reasons, HTTP/3 is significantly more "opaque" than HTTPS with
HTTP/1 or HTTP/2.
Paragraph (version A):
I-D.ietf-quic-manageability discusses manageability of the QUIC
transport protocol that is used to encapsulate HTTP/3, focusing on
the implications of QUIC's design and wire image on network
operations involving QUIC traffic.  It discusses what network
operators can consider in some detail.
Paragraph (version B):
Because HTTPS has historically layered HTTP on top of TLS, which is
in turn layered on top of TCP, intermediaries do have access to
unencrypted TCP-level transport information, such as retransmissions,
and some carriers exploited this information in attempts to improve
transport-layer performance RFC3135.  The most recent standardized
version of HTTPS, HTTP/3 I-D.ietf-quic-http, uses the QUIC protocol
RFC9000 as its transport layer.  QUIC relies on the TLS 1.3 initial
handshake RFC8446 only for key exchange RFC9001, and encrypts almost
all transport parameters itself except for a few invariant header
fields.  In the QUIC short header, the only transport-level parameter
which is sent "in the clear" is the Destination Connection ID
RFC8999, and even in the QUIC long header, the only transport-level
parameters sent "in the clear" are the Version, Destination
Connection ID, and Source Connection ID.  For these reasons, HTTP/3
is significantly more "opaque" than HTTPS with HTTP/1 or HTTP/2.
Paragraph (version B):
I-D.ietf-quic-manageability discusses the manageability of the QUIC
transport protocol that is used to encapsulate HTTP/3, focusing on
the implications of QUIC's design and wire image on network
operations involving QUIC traffic.  It discusses what network
operators can consider in some detail.
Paragraph (version A):
If a content provider does not actively work to avoid interception by
intermediaries, the effect will be indistinguishable from
"impersonation attacks", and endpoints cannot be assumed of any level
of privacy.
Paragraph (version B):
If a content provider does not actively work to avoid interception by
intermediaries, the effect will be indistinguishable from
"impersonation attacks," and endpoints cannot be assumed of any level
of privacy.
Paragraph (version A):
The choice of whether to involve intermediaries sometimes requires
careful consideration.  As an example, when ABR manifests were
commonly sent unencrypted some networks would modify manifests during
peak hours by removing high-bitrate renditions in order to prevent
players from choosing those renditions, thus reducing the overall
bandwidth consumed for delivering these media streams and thereby
improving the network load and the user experience for their
customers.  Now that ubiquitous encryption typically prevents this
kind of modification, in order to maintain the same level of network
health and user experience across networks whose users would have
benefitted from this intervention a media streaming operator
sometimes needs to choose between adding intermediaries who are
authorized to change the manifests or adding significant extra
complexity to their service.
Paragraph (version B):
The choice of whether to involve intermediaries sometimes requires
careful consideration.  As an example, when ABR manifests were
commonly sent unencrypted, some networks would modify manifests
during peak hours by removing high-bitrate renditions to prevent
players from choosing those renditions, thus reducing the overall
bandwidth consumed for delivering these media streams and thereby
improving the network load and the user experience for their
customers.  Now that ubiquitous encryption typically prevents this
kind of modification to maintain the same level of network health and
user experience across networks whose users would have benefited from
this intervention a media streaming operator sometimes needs to
choose between adding intermediaries who are authorized to change the
manifests or adding significant extra complexity to their service.
Paragraph (version A):
"End-to-end" media encryption offers the potential of providing
privacy for streaming media consumers, with the idea being that if an
unauthorized intermediary can't decrypt streaming media, the
intermediary can't use Deep Packet Inspection to examine HTTP request
and response headers and identify the media content being streamed.
Paragraph (version A):
"End-to-end" media encryption has become much more widespread in the
years since the IETF issued "Pervasive Monitoring Is an Attack"
RFC7258 as a Best Current Practice, describing pervasive monitoring
as a much greater threat than previously appreciated.  After the
Snowden disclosures, many content providers made the decision to use
HTTPS protection - HTTP over TLS - for most or all content being
delivered as a routine practice, rather than in exceptional cases for
content that was considered "sensitive".
Paragraph (version A):
Unfortunately, as noted in RFC7258, there is no way to prevent
pervasive monitoring by an "attacker", while allowing monitoring by a
more benign entity who "only" wants to use DPI to examine HTTP
requests and responses in order to provide a better user experience.
If a modern encrypted transport protocol is used for end-to-end media
encryption, intermediary streaming operators are unable to examine
transport and application protocol behavior.  As described in hop-by-
hop-encrypt, only an intermediary streaming operator who is
explicitly authorized to examine packet payloads, rather than
intercepting packets and examining them without authorization, can
continue these practices.
Paragraph (version A):
RFC7258 said that "The IETF will strive to produce specifications
that mitigate pervasive monitoring attacks", so streaming operators
should expect the IETF's direction toward preventing unauthorized
monitoring of IETF protocols to continue for the forseeable future.
Paragraph (version B):
End-to-end media encryption offers the potential of providing privacy
for streaming media consumers, with the idea being that if an
unauthorized intermediary cannot decrypt streaming media, the
intermediary cannot use Deep Packet Inspection to examine HTTP
request and response headers and identify the media content being
streamed.
Paragraph (version B):
End-to-end media encryption has become much more widespread in the
years since the IETF issued "Pervasive Monitoring Is an Attack"
RFC7258 as a Best Current Practice, describing pervasive monitoring
as a much greater threat than previously appreciated.  After the
Snowden disclosures, many content providers made the decision to use
HTTPS protection - HTTP over TLS - for most or all content being
delivered as a routine practice, rather than in exceptional cases for
content that was considered sensitive.
Paragraph (version B):
Unfortunately, as noted in RFC7258, there is no way to prevent
pervasive monitoring by an attacker, while allowing monitoring by a
more benign entity who only wants to use DPI to examine HTTP requests
and responses to provide a better user experience.  If a modern
encrypted transport protocol is used for end-to-end media encryption,
intermediary streaming operators are unable to examine transport and
application protocol behavior.  As described in hop-by-hop-encrypt,
only an intermediary streaming operator who is explicitly authorized
to examine packet payloads, rather than intercepting packets and
examining them without authorization, can continue these practices.
Paragraph (version B):
RFC7258 said that "The IETF will strive to produce specifications
that mitigate pervasive monitoring attacks," so streaming operators
should expect the IETF's direction toward preventing unauthorized
monitoring of IETF protocols to continue for the foreseeable future.