Draft: draft-ietf-mops-streaming-opcons

Commentary: Reverts ietf - wg - mops / draft - ietf - mops - streaming - opcons ( still learning github )
Paragraph (version A):
Because networking resources are shared between users, a good place
to start our discussion is how contention between users, and
mechanisms to resolve that contention in ways that are "fair" between
users, impact streaming media users.  These topics are closely tied
to transport protocol behaviors.
Paragraph (version A):
As noted in sec-abr, Adaptive Bitrate response strategies such as HLS
RFC8216 or DASH 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, these transport protocols,
described in udp-behavior and tcp-behavior, have had relatively
consistent behaviors that have changed slowly, if at all, over time.
Newly standardized transport protocols like QUIC I-D.ietf-quic-
transport can behave differently from existing transport protocols,
and these behaviors may evolve over time more rapidly than currently-
used transport protocols.
Paragraph (version A):
For this reason, we have included a description of how the path
characteristics that streaming media providers may see are likely to
evolve over time.
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).
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.  So, the way some UDP-based applications
interact with other users has changed.
Paragraph (version A):
It's also worth pointing out that because UDP has no transport-layer
feedback mechanisms, UDP-based applications that send and receive
substantial amounts of information are expected to provide their own
feedback mechanisms.  This expectation is most recently codified in
Best Current Practice RFC8085.
Paragraph (version A):
RTP relies on RTCP Sender and Receiver Reports RFC3550 as its own
feedback mechanism, and even includes Circuit Breakers for Unicast
RTP Sessions RFC8083 for situations when normal RTP congestion
control has not been able to react sufficiently to RTP flows sending
at rates that result in sustained packet loss.
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 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
acknowledgments for packets that were successfully sent and received,
and packet timeouts for packets that were not.
Paragraph (version A):
The success of the largely TCP-based Internet is evidence that the
mechanisms TCP used to achieve equilibrium quickly, at a point where
TCP senders do not interfere with other TCP senders for sustained
periods of time, have been largely successful.  The Internet
continued to work even when the specific mechanisms used to reach
equilibrium changed over time.  Because TCP provides a common tool to
avoid contention, as some TCP-based applications like FTP were
largely replaced by other TCP-based applications like HTTP, the
transport behavior remained consistent.
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 COPA 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):
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 A):
The QUIC protocol, developed from a proprietary protocol into an IETF
standards-track protocol I-D.ietf-quic-transport, turns many of the
statements made in udp-behavior and tcp-behavior on their heads.
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.
Paragraph (version A):
While QUIC is designed as a general-purpose transport protocol, and
can carry different application-layer protocols, the current
standardized mapping is for HTTP/3 I-D.ietf-quic-http, which
describes how QUIC transport features are used for HTTP.  The
convention is for HTTP/3 to run over UDP port 443 Port443 but this is
not a strict requirement.
Paragraph (version A):
When HTTP/3 is encapsulated in QUIC, which is then encapsulated in
UDP, streaming operators (and network operators) might see UDP
traffic patterns that are similar to HTTP(S) over TCP.  Since earlier
versions of HTTP(S) rely on TCP, UDP ports may be blocked for any
port numbers that are not commonly used, such as UDP 53 for DNS.
Even when UDP ports are not blocked and HTTP/3 can flow, streaming
operators (and network operators) may severely rate-limit this
traffic because they do not expect to see legitimate high-bandwidth
traffic such as streaming media over the UDP ports that HTTP/3 is
using.
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 A):
The decision to deploy a new version of QUIC is relatively
uncontrolled, compared to other widely used transport protocols, and
this can include new transport behaviors that appear without much
notice except to the QUIC endpoints.  At IETF 105, Christian Huitema
and Brian Trammell presented a talk on "Congestion Defense in Depth"
CDiD, that explored potential concerns about new QUIC congestion
controllers being broadly deployed without the testing and
instrumentation that current major content providers routinely
include.  The sense of the room at IETF 105 was that the current
major content providers understood what is at stake when they deploy
new congestion controllers, but this presentation, and the related
discussion in TSVAREA minutes from IETF 105 (tsvarea-105, are still
worth a look for new and rapidly growing content providers.
Paragraph (version A):
It is worth considering that if TCP-based HTTP traffic and UDP-based
HTTP/3 traffic are allowed to enter operator networks on roughly
equal terms, questions of fairness and contention will be heavily
dependent on interactions between the congestion controllers in use
for TCP-base HTTP traffic and UDP-based HTTP/3 traffic.
Paragraph (version A):
More broadly, I-D.ietf-quic-manageability discusses manageability of
the QUIC transport protocol, 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):
This document introduces no new security issues.