Draft: draft-ietf-mops-streaming-opcons

Commentary: Posted at : 
 We should probably also add  to the acknowledgements . Otherwise , LGTM , and thanks  and  ! 
 I agree with adding  to the ACKs section , but let 's make sure that we 've everyone who has provided last call comments is , and do one PR on that , OK ?
Mailing list commentary: Nits and observations : " handwidth " should be " bandwidth " . " faiis " should be " fails " . ISP acronym is used without expanding the first use for those unfamiliar with it . IXP and used without definition as well . For the acronyms , ISP and VPN might be well known enough to avoid spelling out , but IXP probably needs spelling out the first time . I usually err on the side of spelling them out , though , to avoid ambiguity . Does " goodput " need explanation or do we think readers will be familiar with the term ? Could a reference help here ? " Many assumes " should be " Many assume " or " Many people assume " . Most of the document uses " Adaptive BitRate " , but here we use " Adaptive Bitrate " . We should be consistent with capitalization . " we have trusted the TCP protocol " reads oddly because the P already stands for protocol . Perhaps just " we have trusted TCP " ? Also in the last paragraph with " Although TCP protocol behavior " . " transport protocol behaviors that responds " should be " transport protocol behaviors that respond " . " something completely different " needs full stop . Traffic Control CDN has graduated Apache incubation . The new address is . . * Should most of these links be references ? Or are just links ok ? I know with any kind of linking there 's a risk of staleness , but these are probably useful enough to provide , I ' m just not sure exactly what the right formatting should be . It 's odd to say basically nothing in the " Security Issues " section . We ' ve got multiple sections ( including all of section 6 ) that touch on security and privacy implications of various kinds of behaviours in the streaming media space . Maybe a sentence or two here that points to the rest of the doc while acknowledging that since we 're not defining a new protocol , we 're not creating new problems ? Or maybe it 's fine as is . It just feels strange to me . Procedural question : We have references to drafts in the document . Does its publication need to be held until those references can be resolved ? Relatedly , 7234 is very likely to be obsoleted by draft - ietf - httpbis - cache-19 ( which is in the RFC Editors queue ) soon . Should we update the reference in § 2.4 assuming this document is published after that ? And , of course , an apology for being so very late to review this . It 's a substantial document and it has a lot of really valuable guidance . Perhaps most valuable of all are the very well - collected references that point the reader to a lot of other documents , organizations , and initiatives . If we hammer out the last few details , I support this draft .
Paragraph (version A):
In one example, if a media server overestimates the available
handwidth to the media player,
Paragraph (version B):
In one example, if a media server overestimates the available
bandwidth to the media player,
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 RFC7234).  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):
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 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 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
ISP to attempt to "throttle" these transfers, to mitigate the load
that these hosts placed on their network.  These efforts were met by
increased use of encryption in Bittorrent, similar to an arms race,
and set off discussions about "Net Neutrality" and calls for
regulatory action.
Paragraph (version B):
The combination of the large volume of "torrents" and the peer-to-
peer characteristic of swarm transfers meant that end user hosts were
suddenly uploading higher volumes of traffic to more destinations
than was the case before Bittorrent.  This caused at least one large
internet service provider (ISP) to attempt to "throttle" these
transfers, to mitigate the load that these hosts placed on their
network.  These efforts were met by increased use of encryption in
Bittorrent, similar to an arms race, and set off discussions about
"Net Neutrality" and calls for regulatory action.
Paragraph (version A):
Reported traffic increases from ISPs and IXPs over just a few
weeks were as big as the traffic growth over the course of a
typical year, representing a 15-20% surge in growth to land at a
new normal that was much higher than anticipated.
Paragraph (version B):
Reported traffic increases from ISPs and internet exchange points
(IXP) over just a few weeks were as big as the traffic growth over
the course of a typical year, representing a 15-20% surge in
growth to land at a new normal that was much higher than
anticipated.
Paragraph (version A):
The increase in daytime bandwidth consumption reflected both
significant increases in "essential" applications such as
videoconferencing and VPNs, 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):
Adaptive BitRate (ABR) is a sort of application-level response
strategy in which the streaming client attempts to detect the
available bandwidth of the network path by observing the successful
application-layer download speed, then chooses a bitrate for each of
the video, audio, subtitles and metadata (among the limited number of
available options) that fits within that bandwidth, typically
adjusting as changes in available bandwidth occur in the network or
changes in capabilities occur during the playback (such as available
memory, CPU, display size, etc.).
Paragraph (version B):
ABR is a sort of application-level response strategy in which the
streaming client attempts to detect the available bandwidth of the
network path by observing the successful application-layer download
speed, then chooses a bitrate for each of the video, audio, subtitles
and metadata (among the limited number of available options) that
fits within that bandwidth, typically adjusting as changes in
available bandwidth occur in the network or changes in capabilities
occur during the playback (such as available memory, CPU, display
size, etc.).
Paragraph (version A):
These effects and others that cause transport behavior to diverge
from lab modeling can sometimes have a significant impact on ABR
bitrate selection and on user quality of experience, especially where
players use naive measurement strategies and selection algorithms
that don't account for the likelihood of bandwidth measurements that
diverge from the true path capacity.
Paragraph (version B):
These effects and others that cause transport behavior to diverge
from lab modeling can sometimes have a significant impact on bitrate
selection and on user quality of experience, especially where players
use naive measurement strategies and selection algorithms that don't
account for the likelihood of bandwidth measurements that diverge
from the true path capacity.
Paragraph (version A):
As noted in sec-abr, Adaptive Bitrate response strategies such as HLS
RFC8216 or DASH MPEG-DASH are attempting to respond to changing path
characteristics, and underlying transport protocols are also
attempting to respond to changing path characteristics.
Paragraph (version B):
As noted in sec-abr, ABR response strategies such as HLS RFC8216 or
DASH MPEG-DASH are attempting to respond to changing path
characteristics, and underlying transport protocols are also
attempting to respond to changing path characteristics.
Paragraph (version A):
For most of the history of the Internet, we have trusted the TCP
protocol 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):
Although TCP protocol behavior has changed over time, the common
practice of implementing TCP as part of an operating system kernel
has acted to limit how quickly TCP behavior can change.  Even with
the widespread use of automated operating system update installation
on many end-user systems, streaming media providers could have a
reasonable expectation that they could understand TCP transport
protocol behaviors, and that those behaviors would remain relatively
stable in the short term.
Paragraph (version B):
Although TCP behavior has changed over time, the common practice of
implementing TCP as part of an operating system kernel has acted to
limit how quickly TCP behavior can change.  Even with the widespread
use of automated operating system update installation on many end-
user systems, streaming media providers could have a reasonable
expectation that they could understand TCP transport protocol
behaviors, and that those behaviors would remain relatively stable in
the short term.
Paragraph (version B):
As noted in tcp-behavior, there is increasing interest in transport
protocol behaviors that respond to delay measurements, instead of
responding to packet loss.  These behaviors may deliver improved user
experience, but in some cases have not responded to sustained packet
loss, which exhausts available buffers along the end-to-end path that
may affect other users sharing that path.  The QUIC protocol provides
a set of congestion control hooks that can be use for algorithm
agility, and RFC9002 defines a basic algorithm with transport
behavior that is roughly similar to TCP NewReno RFC6582.  However,
QUIC senders can and do unilaterally choose to use different
algorithms such as loss-based CUBIC RFC8312, delay-based COPA or BBR,
or even something completely different.
Paragraph (version B):
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):
This document introduces no new security issues.
Paragraph (version B):
Security is an important matter for streaming media applications and
it was briefly touched on in gen-encrypt.  This document itself
introduces no new security issues.