Draft: draft-ietf-mops-streaming-opcons

Commentary: Also removed ECN - I thought we did that ! 
 Submitted as -05
Paragraph (version A):
As the internet has grown, an increasingly large share of the traffic
delivered to end users has become video.  Estimates put the total
share of internet video traffic at 75% in 2019, expected to grow to
82% by 2022.  What's more, this estimate projects the gross volume of
video traffic will more than double during this time, based on a
compound annual growth rate continuing at 34% (from Appendix D of
CVNI).
Paragraph (version B):
As the internet has grown, an increasingly large share of the traffic
delivered to end users has become video.  Estimates put the total
share of internet video traffic at 75% in 2019, expected to grow to
82% by 2022.  This estimate projects the gross volume of video
traffic will more than double during this time, based on a compound
annual growth rate continuing at 34% (from Appendix D of CVNI).
Paragraph (version A):
This document specifically focuses on the streaming applications and
defines streaming as follows: Streaming is transmission of a
continuous media from a server to a client and its simultaneous
consumption by the client.  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.
This has two implications.  First, server's transmission rate must
(loosely or tightly) match to client's consumption rate for an
uninterrupted playback.  That is, the client must not run out of data
(buffer underrun) or take more than it can keep (buffer overrun) as
any excess media is simply discarded.  Second, client's consumption
rate is limited by not only bandwidth availability but also the real-
time constraints.  That is, the client cannot fetch media that is not
available yet.
Paragraph (version B):
Streaming is transmission of a 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 video file and plays it after the download is
completed, which would be called download-and-play.
Paragraph (version B):
This has two implications.
Paragraph (version B):
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 is simply
discarded.
Paragraph (version B):
Second, the client's consumption rate is limited not only by
bandwidth availability but also real-time constraints.  That is,
the client cannot fetch media that is not available from a server
yet.
Paragraph (version A):
Here are a few common resolutions used for video content, with
typical ranges of bitrae for the two most popular video codecs
Encodings.
Paragraph (version A):
Even the basic virtual reality (360-degree) videos (that allow users
to look around freely, referred to as three degrees of freedom -
3DoF) require substantially larger bitrates when they are captured
and encoded as such videos require multiple fields of view of the
scene.  The typical multiplication factor is 8 to 10.  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.
Paragraph (version B):
Here are a few common resolutions used for video content, with
typical ranges of bitrate for the two most popular video codecs
Encodings.
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.  The typical multiplication factor is 8 to 10.  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.
Paragraph (version A):
In more immersive applications, where basic user movement (3DoF+) or
full user movement (6DoF) is allowed, the required bitrate grows even
further.  In this case, the 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):
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):
Caching and pre-loading can also reduce exposure to peering point
congestion, since less traffic crosses the peering point exchanges if
the caches are placed in peer networks, especially when the content
can be pre-loaded during off-peak hours, and especially if the
transfer can make use of "Lower-Effort Per-Hop Behavior (LE PHB) for
Differentiated Services" RFC8622, "Low Extra Delay Background
Transport (LEDBAT)" RFC6817, or similar mechanisms.
Paragraph (version A):
Cross-ref vs. video quality by time of day in practice for some case
study?  Not sure if there's a good way to capture a generalized
insight here, but it seems worth making the point that demand
projections can be used to help with e.g. power consumption with
routing architectures that provide for modular scalability.
Paragraph (version B):
TBD: Cross-ref vs. video quality by time of day in practice for some
case study?  Not sure if there's a good way to capture a generalized
insight here, but it seems worth making the point that demand
projections can be used to help with e.g. power consumption with
routing architectures that provide for modular scalability.
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 quite large.
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 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 does not, because application bandwidth usage
patterns have changed.
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 faiis because application bandwidth usage
patterns have changed in ways that were not predicted.
Paragraph (version A):
Although QUIC provides an alternative to the TCP and UDP transport
protocols, QUIC is itself encapsulated in UDP.  As noted elsewhere in
this document, the QUIC protocol encrypts almost all of its transport
parameters, and all of its payload, so any intermediaries that
network operators may be using to troubleshoot HTTP streaming media
performance issues, perform analytics, or even intercept exchanges in
current applications will not work for QUIC-based applications
without making changes to their networks. stream-encrypt-media
describes the implications of media encryption in more detail.
Paragraph (version B):
Although QUIC provides an alternative to the TCP and UDP transport
protocols, QUIC is itself encapsulated in UDP.  As noted elsewhere in
gen-encrypt, the QUIC protocol encrypts almost all of its transport
parameters, and all of its payload, so any intermediaries that
network operators may be using to troubleshoot HTTP streaming media
performance issues, perform analytics, or even intercept exchanges in
current applications will not work for QUIC-based applications
without making changes to their networks. stream-encrypt-media
describes the implications of media encryption in more detail.
Paragraph (version A):
A QUIC extension currently being specified (I-D.ietf-quic-datagram)
adds the capability for "unreliable" delivery, similar to the service
provided by UDP, but these datagrams are still subject to the QUIC
connection's congestion controller, providing some transport-level
congestion avoidance measures, which UDP is not.
Paragraph (version B):
A QUIC extension currently being specified (I-D.ietf-quic-datagram)
adds the capability for "unreliable" delivery, similar to the service
provided by UDP, but these datagrams are still subject to the QUIC
connection's congestion controller, providing some transport-level
congestion avoidance measures, which UDP does not.
Paragraph (version A):
We do have experience with deploying new congestion controllers
without melting the Internet (CUBIC is one example), but the point
mentioned in tcp-behavior about TCP being implemented in operating
system kernels is also 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 with applications.
Paragraph (version B):
We do have experience with deploying new congestion controllers
without melting the Internet (CUBIC is one example), but the point
mentioned in tcp-behavior about TCP being implemented in operating
system kernels is also 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.
Paragraph (version A):
Media encrypted at the application layer, typically using some
sort of Digital Rights Management (DRM) system, and typically
retaining this encryption "at rest", when it is stored at senders
and receivers,
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 A):
Each of these encryption strategies is intended to achieve a
different goal.  For instance, application-level encryption may be
used for business purposes, such as avoiding piracy or enforcing
geographic restrictions on playback, while transport-layer encryption
may be used to prevent media steam manipulation or to protect
manifests.  This document does not take a position on whether those
goals are "valid" (whatever that might mean).
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".
Paragraph (version A):
Both "End-to-End" and "Hop-by-Hop" media encryption have implications
for streaming operators.
Paragraph (version B):
Each of these encryption strategies is intended to achieve a
different goal.  For instance, application-level encryption may be
used for business purposes, such as avoiding piracy or enforcing
geographic restrictions on playback, while transport-layer encryption
may be used to prevent media steam manipulation or to protect
manifests.
Paragraph (version B):
This document does not take a position on whether those goals are
"valid" (whatever that might mean).
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.
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.