Draft: draft-ietf-mops-streaming-opcons

Commentary: … transport protocols Also tighten up description of the assumed protocol stack in ( what is now ) Section 6.1 . Note that the UDP and TCP sections have been flipped in order , to improve section flow and clarity . 
 - If you have a moment before our call on Friday to take a look at this PR , I 'd appreciate it . I think it 's important to to get that right , in order to address both the INTDIR and TSVART reviews . 
 From As a bit of transport commentary , I do n't find the setup of Section 6 compelling . While UDP is a transport in a technical sense , for the purpose of media , it is almost always a layer upon which the protocol doing the congestion control work runs . To that end , QUIC is just another more standardized case of this , just like SCTP over UDP . Rather than talking about " UDP 's behavior " vs " TCP 's behavior " , I suggest talking about how applications over UDP for media behave vs applications over TCP for media behave . 
 - I need to look at this more closely . I understand your point about UDP , but ( because UDP is not a real transport layer , while TCP and QUIC are ) , I suspect ( without looking closely yet ) I 'm going to be making sure that I explain this more clearly , without trying to explain the behavior(s ) of applications running over TCP and QUIC . As an aside , I 'm trying to make this clearer in drafts I 'm targeting forwards Media Over QUIC / MOQ , so I actually DO believe you ... Please await results . 
 A +1 from 's review ( ): Section 6 . Evolution of Transport Protocols and Transport Protocol Behaviors I really wonder whether UDP vs.  vs. QUIC is actually the relevant distinction . What may actually matter are the transport services provided by the protocol stack ( e.g. , RFC 8095 ) . I fully agree to a related comment in the INTDIR review . 
 After looking at this issue . I agree with both and that the emphasis should be on the interaction between ( see new section describing this ) media transport protocols and the transport services provided by underlying transport protocols . I 'm moving the formerly - UDP section below the formerly - TCP section , because it 's easier to describe what UDP is NOT doing after describing what TCP IS doing . I 'm also moving one paragraph into the formerly - TCP section from Section 6 , because it is specific to ABR strategies that assume a reliable transport . More news to come , when I create a PR for this issue ... 
 We think is now mergrable .
Mailing list commentary: Reviewer : Review result : Ready with Issues This document has been reviewed as part of the transport area review team 's ongoing effort to review key IETF documents . These comments were written primarily for the transport area directors , but are copied to the document 's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information . When done at the time of IETF Last Call , the authors should consider this review as part of the last - call comments they receive . Please always CC tsv- if you reply to or forward this review . This informational document surveys network and transport protocol issues that affect quality of experience for streaming applications , in particular video . The overview covers many topics across different technologies . Readers may only be familiar with a subset of these topics and could therefore learn quite a bit from this kind of tutorial . Nonetheless , it remains somewhat unclear what the actual objective of some of the text is . For some topics , quite a bit of technical background is provided , but the discussion is not really comprehensive . In many sections , the document neither derives technical challenges , nor system / protocol requirements , nor practical usage guidance . It is just a kind of tutorial . Quite a bit of text also presents ongoing IETF work , and an RFC with this scope may thus get outdated soon . Section 6.2 deals with topics owned by TCPM . In similar past documents , I have asked for a TCPM presentation prior to an IETF last call in order to ensure that owners of running code are in the loop . I believe this strategy has worked well in the past . Having said this , as TSV - ART reviewer I do n't strongly disagree with a publication . All these issues may just be OK for an informational RFC . Some more specific comments : Section 3.2.1 . from an Expected Baseline This section apparently assumes relatively static path properties , e.g. , fixed network connectivity . It would be more useful to analyze the impact of and 4G/5 G networks in one place . Some of this follows later in sections 3.2.1 and 5.5.3 . Yet , the split between these three sections is unclear . Having a discussion about today 's Internet path characteristics and the dynamics at one place could be more useful . The text could also better distinguish between what matters to endpoints and considerations relevant only for middleboxes ( such as passive monitors ) . Section 3.3 Path Requirements The statement " to find the bandwidth requirements for a router on the delivery path " may assume that the bottleneck on the path will be routers . Yet , on a path the bottlenecks could also be a link layer device ( e.g. , an   , a access point , etc . ) . RFC 6077 ( specifically Section 3.1.3 ) also explains that issue . A better wording may be " to find the bandwidth requirements for a delivery path " . Section 3.6 . Unpredictable Usage Profiles / Section 3.7 . Extremely Unpredictable Usage Profiles I am not fully convinced by the distinction between " unpredictable " and " extremely unpredictable " . To me , these two sections could be merged and maybe also be shortened . More specifically , Section 3.7 lists a lot of statistics from the past . What is IMHO a bit missing in Section 3.7 are actual operational considerations . For instance , are there any lessons learnt for the future ? Note that Section 3.6 has a reasonable conclusion at the end . Section 4 . Latency Considerations and Section 4.1 . I am surprised by the definition " ultra low - latency ( less than 1 second ) " , as well as some of the other numbers . For other real - time communication use cases , " ultra low - latency " would probably imply a latency requirement of the order of one millisecond . For instance , isochronous traffic for motion control in industrial networks may require a latency of 1 ms , and such " ultra - low latency " requirements are discussed elsewhere , e.g. , in the DetNet WG . The terminology in this section should be better explained to readers dealing with networked systems with much harder latency requirements . And a reference should be for these definitions in the context of video streaming . Section 5.5.2 Head - of - Line Blocking If Head - of - Line Blocking is indeed a relevant operational problem , it would be useful to add a corresponding reference ( e.g. , with measurements ) . Section 5.5.3 . Wide and Rapid Variation in Path Capacity The statement " As many end devices have moved to wireless connectivity for the final hop ( Wi - Fi , 5 G , or LTE ) , new problems in bandwidth detction have emerged from radio interference and signal strength effects . " could be moved to earlier parts of the document . Quite a bit of new computers apparently only have connectivity and no Ethernet port , i.e. , may just be their default . Also , wireless may not only be used on the last hop , for instance in meshed setups . This may make the problem even harder . Section 6 . Evolution of Transport Protocols and Transport Protocol Behaviors I really wonder whether UDP vs. vs. QUIC is actually the relevant distinction . What may actually matter are the transport services provided by the protocol stack ( e.g. , RFC 8095 ) . I fully agree to a related comment in the INTDIR review . Section 6.1 . UDP and Its Behavior UDP is also used for encrypted tunnels ( OpenVPN , Wireguard , etc . ) . Does encrypted tunneling really have no operational impact on streaming other than circuit breakers ? ( I am thinking about 4 K streaming over OpenVPN and the like . ) Section 6.2 . TCP and Its Behavior This text should IMHO be presented and be discussed in TCPM . Personally , I am not convinced that this document is a good place for discussing the long history of TCP congestion control . If the objective of the document is to provide a tutorial , IMHO it would be more useful to briefly explain the state - of - the - art in year 2022 . Some further specific comments on TCP congestion control : It is surprising that RFC 5681 is not referenced .793bis has normative statements regarding congestion control , and most stacks are compatible to what is written in 793bis . Several operating systems use CUBIC by default and support standard Reno . Another general good reference for TCP standards is RFC 7414 .Does ECN , DCTCP , etc . really not matter at all , for instance , if a data center hosts video playout servers ? Section 6.3 . QUIC and Its Behavior As already noted , the discussion about head - of - line - blocking would really benefit from backing by a reference . Section 7 . Streaming Encrypted Media As far as I know , streaming users sometimes use encrypted tunnels such as OpenVPN or WireGuard ( or IPsec ) to access video content . I may miss something , but it is unclear to me how that fits into the categories presented in Section 7 .
Paragraph (version A):
Various HTTP versions have been used for media delivery.  HTTP/1.0,
HTTP/1.1 and HTTP/2 are carried over TCP, and TCP's transport
behavior is described in tcp-behavior.  HTTP/3 is carried over QUIC,
and QUIC's transport behavior is described in quic-behavior.
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 packet loss occurs, the most appropriate response may
depend on the type of codec being used.
Paragraph (version B):
Various HTTP versions have been used for media delivery.  HTTP/1.0,
HTTP/1.1 and HTTP/2 are carried over TCP, and TCP's transport
behavior is described in reliable-behavior.  HTTP/3 is carried over
QUIC, and QUIC's transport behavior is described in quic-behavior.
Paragraph (version B):
Unreliable media delivery using RTP and other UDP-based protocols is
also discussed in ultralow, unreliable-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):
even if the TCP payload itself is encrypted.  See tcp-behavior for
more information.
Paragraph (version A):
As transport protocols evolve to encrypt their transport header
fields, one side effect of increasing encryption is the kind of
passive monitoring, or even "performance enhancement" (RFC3135) that
was possible with the older transport protocols (UDP, described in
udp-behavior and TCP, described in tcp-behavior) is no longer
possible with newer transport protocols such as QUIC (described in
quic-behavior).  The IETF has specified a "latency spin bit"
mechanism in Section 17.4 of RFC9000 to allow passive latency
monitoring from observation points on the network path throughout the
duration of a connection, but currently chartered work in the IETF is
focusing on endpoint monitoring and reporting, rather than on passive
monitoring.
Paragraph (version B):
even if the TCP payload itself is encrypted.  See reliable-behavior
for more information.
Paragraph (version B):
As transport protocols evolve to encrypt their transport header
fields, one side effect of increasing encryption is the kind of
passive monitoring, or even "performance enhancement" (RFC3135) that
was possible with the older transport protocols (UDP, described in
unreliable-behavior and TCP, described in reliable-behavior) is no
longer possible with newer transport protocols such as QUIC
(described in quic-behavior).  The IETF has specified a "latency spin
bit" mechanism in Section 17.4 of RFC9000 to allow passive latency
monitoring from observation points on the network path throughout the
duration of a connection, but currently chartered work in the IETF is
focusing on endpoint monitoring and reporting, rather than on passive
monitoring.
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, 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, 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 RFC9000 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):
"Media Format" would be something like an RTP payload format
RFC2736 or ISOBMFF ISOBMFF,
Paragraph (version A):
"Transport Protocol" would be something like TCP or UDP.
Paragraph (version A):
It is worth noting explicitly that the Media Transport Protocol and
Transport Protocol layers might each include more than one protocol.
For example, a Media Transport Protocol might run over HTTP, or over
WebTransport, which in turn runs over HTTP.
Paragraph (version A):
It is worth noting explicitly that more complex network protocol
stacks are certainly possible - for instance, packets with this
protocol stack may be carried in a tunnel, or in a VPN.  If these
environments are present, streaming media operators may need to
analyze their effects on applications as well.
Paragraph (version B):
"Media" would be something like the output of a codec, or other
media source such as closed-captioning,
Paragraph (version B):
"Media Format" would be something like an RTP payload format
RFC2736 or an ISOBMFF ISOBMFF profile,
Paragraph (version B):
"Transport Protocol" would be a protocol that provides appropriate
transport services, as described in Section 5 of RFC8095.
Paragraph (version B):
Not all possible streaming media applications follow this model, but
for the ones that do, it seems useful to distinguish between the
protocol layer that is aware it is transporting media, and underlying
protocol layers that are not aware.
Paragraph (version B):
Transport protocols used to provide unreliable, unordered media
delivery to an endpoint, without flow control or congestion
control (unreliable-behavior).
Paragraph (version B):
Because newly standardized transport protocols such as QUIC RFC9000
can evolve their transport behavior more rapidly than currently-used
transport protocols, we have included a description of how the path
characteristics that streaming media providers may see are likely to
evolve in quic-behavior.
Paragraph (version B):
It is worth noting explicitly that the Transport Protocol layer might
include more than one protocol.  For example, a specific Media
Transport Protocol might run over HTTP, or over WebTransport, which
in turn runs over HTTP.
Paragraph (version B):
It is worth noting explicitly that more complex network protocol
stacks are certainly possible - for instance, when packets with this
protocol stack are carried in a tunnel or in a VPN, the entire packet
would likely appear in the payload of other protocols.  If these
environments are present, streaming media operators may need to
analyze their effects on applications as well.
Paragraph (version B):
The HLS RFC8216 and DASH MPEG-DASH media transport protocols are
typically carried over HTTP, and HTTP has used TCP as its only
standardized transport protocol until HTTP/3 RFC9114.  These media
transport protocols use ABR response strategies as described in sec-
abr to respond to changing path characteristics, and underlying
transport protocols are also attempting to respond to changing path
characteristics.
Paragraph (version B):
The past success of the largely TCP-based Internet is evidence that
the various flow control and congestion control mechanisms TCP has
used to achieve equilibrium quickly, at a point where TCP senders do
not interfere with other TCP senders for sustained periods of time
(RFC5681), have been largely successful.  The Internet has continued
to work even when the specific TCP mechanisms used to reach
equilibrium changed over time (RFC7414).  Because TCP provided a
common tool to avoid contention, even when significant TCP-based
applications like FTP were largely replaced by other significant TCP-
based applications like HTTP, the transport behavior remained safe
for the Internet.
Paragraph (version B):
Modern TCP implementations (I-D.ietf-tcpm-rfc793bis) continue to
probe for available bandwidth, and "back off" when a network path is
saturated, but may also work to avoid growing queues along network
paths, which can prevent older TCP senders from detecting quickly
when a network path is becoming 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
network can forward them (or the receiver can accept them) so the
sender should adjust its sending rate accordingly.
Paragraph (version A):
Because UDP does not provide any feedback mechanism to senders to
help limit impacts on other users, UDP-based application-level
protocols 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):
Because UDP does not provide any feedback mechanism to senders to
help limit impacts on other users, UDP-based application-level
protocols 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 as a Best
Current Practice RFC8085.
Paragraph (version A):
The past 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 (RFC5681), have been largely successful.
The Internet has continued to work even when the specific TCP
mechanisms used to reach equilibrium changed over time (RFC7414).
Because TCP provides a common tool to avoid contention, even when
significant TCP-based applications like FTP were largely replaced by
other significant TCP-based applications like HTTP, the transport
behavior remained safe for the Internet.
Paragraph (version A):
Modern TCP implementations (I-D.ietf-tcpm-rfc793bis) continue to
probe for available bandwidth, and "back off" when a network path is
saturated, but may also work to avoid growing queues along network
paths, which prevent TCP senders from detecting quickly when a
network path becoming 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 network can forward them (or
the receiver can accept them) so the sender should adjust its sending
rate accordingly.
Paragraph (version A):
The QUIC protocol, developed from a proprietary protocol into an IETF
standards-track protocol RFC9000, turns many of the statements made
in udp-behavior and tcp-behavior on their heads.
Paragraph (version B):
The QUIC protocol, developed from a proprietary protocol into an IETF
standards-track protocol RFC9000, turns many of the statements made
in reliable-behavior and unreliable-behavior on their heads.
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 B):
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 RFC9114, which describes how QUIC
transport services 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 B):
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.  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 QUIC packets
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):
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):
The point mentioned in reliable-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):
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):
Because HTTPS has historically layered HTTP on top of TLS, which is
in turn layered on top of TCP, intermediaries have historically had
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 RFC9114, 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.