Draft: draft-ietf-mops-streaming-opcons

Commentary: From 
 Two observations here . Many of these comments are n't quite editorial , but should be straightforward to resolve . I noticed two or three comments that seemed less obvious to resolve , but if that 's true , we can move them into their own issues ( and remove them from this one ) . this is a heck of a good review , and obviously the result of a very close read . I 'll remember this , the next time  is reviewing one of my documents ! : smiling_imp : 
 Two MORE observations here ... Roman has a good collection of " is THIS the same as THAT ? " questions . We 've addressed some of these in other issues , but we need to go through list and make sure we addressed them all . Roman also has detailed questions on Section 7 and its subsections that need to be worked through in more detail . We think some of the questions are actually more about DRM than the media we 've been talking about in this document . More details to come , as we work through this , but at a minimum we need to add appropriate redirections to DRM specifications in our text . 
 I want to take some work off of plate . I 'll submit a PR , and he and can tell us what I should have said . : upsidedownface : 
 Discussion of Roman 's ballot comments is . 
 Thanks  , much appreciated . Suggested a few nits , otherwise lgtm .
Paragraph (version A):
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):
All of this depends, of course, on the ability of a media provider to
predict usage and provision bandwidth, caching, and other mechanisms
to meet the needs of users.  In some cases (sec-predict), this is
relatively routine, but in other cases, it is more difficult (sec-
unpredict).
Paragraph (version A):
And as with other parts of the ecosystem, new technology brings new
challenges.  For example, with the emergence of ultra-low-latency
streaming, responses have to start streaming to the end user while
still being transmitted to the cache, and while the cache does not
yet know the size of the object.  Some of the popular caching systems
were designed around cache footprint and had deeply ingrained
assumptions about knowing the size of objects 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 a playback 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 media for all players playing the segment
delivered from that cache node.
Paragraph (version A):
Historical data shows that users consume more videos and these videos
are encoded at a bitrate higher than they were in the past.
Improvements in the codecs that help reduce the encoding bitrates
with better compression algorithms could not have offset the increase
in the demand for the higher quality video (higher resolution, higher
frame rate, better color gamut, better dynamic range, etc.).  In
particular, mobile data usage has shown a large jump over the years
due to increased consumption of entertainment and conversational
video.
Paragraph (version 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.  This is especially true when
the content can be pre-loaded during off-peak hours, and 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 B):
All of this depends, of course, on the ability of a streaming media
operator to predict usage and provision bandwidth, caching, and other
mechanisms to meet the needs of users.  In some cases (sec-predict),
this is relatively routine, but in other cases, it is more difficult
(sec-unpredict).
Paragraph (version B):
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
a playback 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
media 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 bitrate higher than they were in the past.
Improvements in the codecs that help reduce the encoding bitrates
with better compression algorithms have not 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 in cellular access networks has shown a
large jump over the years due to increased consumption of
entertainment and conversational video.
Paragraph (version A):
Some media content providers aim to achieve this level of latency for
live media events.  This introduces new challenges relative to less-
restricted levels of latency requirements because this latency is the
same scale as commonly observed end-to-end network latency variation
(for example, due to effects such as bufferbloat (CoDel), Wi-Fi error
correction, or packet reordering).  These effects can make it
difficult to achieve this level of latency for the general case, and
may require tradeoffs in relatively frequent user-visible media
artifacts.  However, for controlled environments or targeted networks
that provide mitigations against such effects, this level of latency
is potentially achievable with the right provisioning.
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):
Some media content providers aim to achieve this level of latency for
live media events.  This introduces new challenges when compared to
the other latency categories described in latency-cons, because
ultra-low-latency is on the same scale as commonly observed end-to-
end network latency variation, often due to bufferbloat (CoDel), Wi-
Fi error correction, or packet reordering.  These effects can make it
difficult to achieve ultra-low-latency for many users, and may
require accepting relatively frequent user-visible media artifacts.
However, for controlled environments that provide mitigations against
such effects, ultra-low-latency is potentially achievable with the
right provisioning and the right media transport technologies.
Paragraph (version A):
Worth noting is that many applications for ultra-low-latency delivery
do not need to scale to as many users as the low-latency and non-low-
latency live delivery, 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 as many users as applications for low-latency
and non-low-latency live delivery, which simplifies many delivery
considerations.
Paragraph (version A):
This level of latency is the historically common case for segmented
media delivery using HLS and DASH.  This level of latency is often
considered adequate for content like news or pre-recorded content.
This level of latency is also sometimes achieved as a fallback state
when some part of the delivery system or the client-side players do
not have the necessary support for the features necessary to support
low-latency live streaming.
Paragraph (version B):
This level of latency is the historically common case for segmented
media delivery using HLS and DASH.  This level of latency is often
considered adequate for content like news.  This level of latency is
also sometimes achieved as a fallback state when some part of the
delivery system or the client-side players do not have the necessary
support for the features necessary to support low-latency live
streaming.
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 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 Internet community does have experience with deploying new
congestion controllers without causing congestion collapse on 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, both
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 A):
Media encrypted at the application layer, typically using some
sort of Digital Rights Management (DRM) system, and typically
remaining encrypted at rest, when senders and receivers store it.
Paragraph (version B):
Media encrypted at the application layer, typically using some
sort of Digital Rights Management (DRM) system or other object
encryption/security mechanism, and typically remaining encrypted
at rest, when senders and receivers store it.
Paragraph (version A):
The use of strong encryption does provide confidentiality for
encrypted streaming media, from the sender to either an intermediary
or the ultimate media consumer, and this does prevent Deep Packet
Inspection by any intermediary that does not possess credentials
allowing decryption.  However, even encrypted content streams may be
vulnerable to traffic analysis.  An intermediary that can identify an
encrypted media stream without decrypting it, may be able to
"fingerprint" the encrypted media stream of known content, and then
match the targeted media stream against the fingerprints of known
content.  This protection can be lessened if a media provider is
repeatedly encrypting the same content.  CODASPY17 is an example of
what is possible when identifying HTTPS-protected videos over TCP
transport, based either on the length of entire resources being
transferred, or on characteristic packet patterns at the beginning of
a resource being transferred.
Paragraph (version A):
If traffic analysis is successful at identifying encrypted content
and associating it with specific users, this breaks privacy as
certainly as examining decrypted traffic.
Paragraph (version B):
The use of strong encryption does provide confidentiality for
encrypted streaming media, from the sender to either the ultimate
media consumer, or to an intermediary that possesses credentials
allowing decryption.  This does prevent Deep Packet Inspection by any
on-path intermediary that does not possess credentials allowing
decryption.  However, even encrypted content streams may be
vulnerable to traffic analysis.  An on-path observer that can
identify that encrypted traffic contains a media stream, could
"fingerprint" this encrypted media steam, and then compare it against
"fingerprints" of known content.  The protection provided by strong
encryption can be further lessened if a streaming media operator is
repeatedly encrypting the same content.  "Identifying HTTPS-Protected
Netflix Videos in Real-Time" (CODASPY17) is an example of what is
possible when identifying HTTPS-protected videos over TCP transport,
based either on the length of entire resources being transferred, or
on characteristic packet patterns at the beginning of a resource
being transferred.  If traffic analysis is successful at identifying
encrypted content and associating it with specific users, this tells
an on-path observer what resource is being streamed, and by who,
almost as certainly as examining decrypted traffic.
Paragraph (version B):
Hop-by-hop media encryption offers the benefits described in gen-
encrypt between the streaming media operator and authorized
intermediaries, among authorized intermediaries, and between
authorized intermediaries and the ultimate media consumer, but does
not provide these benefits end-to-end.  The streaming media operator
and ultimate media consumer must trust the authorized intermediaries,
and if these intermediaries cannot be trusted, the benefits of
encryption are lost.
Paragraph (version A):
From a media provider's perspective, a number of considerations are
in play.  The first question is likely whether the media provider
intends that intermediaries are explicitly addressed from endpoints,
or whether the media provider is willing to allow intermediaries to
"intercept" streaming content transparently, with no awareness or
permission from either endpoint.
Paragraph (version A):
If a media 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):
Server And Network assisted DASH MPEG-DASH-SAND - this
specification introduces explicit messaging between DASH clients
and network elements or between various network elements for the
purpose of improving the efficiency of streaming sessions by
providing information about real-time operational characteristics
of networks, servers, proxies, caches, CDNs, as well as DASH
client's performance and status.
Paragraph (version B):
From a streaming media operator's perspective, a number of
considerations are in play.  The first question is likely whether the
streaming media operator intends that intermediaries are explicitly
addressed from endpoints, or whether the streaming media operator is
willing to allow intermediaries to "intercept" streaming content
transparently, with no awareness or permission from either endpoint.
Paragraph (version B):
If a streaming media operator does not actively work to avoid
interception by on-path intermediaries, the effect will be
indistinguishable from "impersonation attacks," and endpoints cannot
be assured of any level of confidentiality, and cannot trust that the
content received came from the expected sender.
Paragraph (version B):
Server And Network assisted DASH MPEG-DASH-SAND - this
specification introduces explicit messaging between DASH clients
and DASH-aware network elements or among various DASH-aware
network elements, for the purpose of improving the efficiency of
streaming sessions by providing information about real-time
operational characteristics of networks, servers, proxies, caches,
CDNs, as well as DASH client's performance and status.
Paragraph (version A):
Secure Media Frames SFRAME - RFC8723 is closely tied to SRTP, and
this close association impeded widespread deployment, because it
could not be used for the most common media content delivery
mechanisms.  A more recent proposal, Secure Media Frames SFRAME,
also provides both hop-by-hop and end-to-end security guarantees,
but can be used with other transport protocols beyond SRTP.
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 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, a streaming media provider who used
intermediaries in the past, and who now wishes to maintain the same
level of network health and user experience, must choose between
adding intermediaries who are authorized to change the manifests or
adding some other form of complexity to their service.
Paragraph (version B):
Secure Media Frames SFRAME - RFC8723 is closely tied to SRTP, and
this close association impeded widespread deployment, because it
could not be used for the most common media content delivery
mechanisms.  A more recent proposal, Secure Media Frames SFRAME,
also provides both hop-by-hop and end-to-end security guarantees,
but can be used with other media transport protocols beyond SRTP.
Paragraph (version B):
A streaming media operator's choice of whether to involve
intermediaries requires careful consideration.  As an example, when
ABR manifests were commonly sent unencrypted, some access network
operators 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, a streaming media
operator who used intermediaries in the past, and who now wishes to
maintain the same level of network health and user experience, must
choose between adding intermediaries who are authorized to change the
manifests or adding some other form of 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 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 offers the benefits described in gen-
encrypt from the streaming media operator to the ultimate media
consumer.
Paragraph (version A):
However, 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 explicitly authorized by the streaming media
provider who is to examine packet payloads, rather than intercepting
packets and examining them without authorization, can continue these
practices.
Paragraph (version B):
However, 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,
unauthorized on-path intermediaries are unable to examine transport
and application protocol behavior.  As described in hop-by-hop-
encrypt, only an intermediary explicitly authorized by the streaming
media operator who is to examine packet payloads, rather than
intercepting packets and examining them without authorization, can
continue these practices.