Draft: draft-ietf-mops-streaming-opcons

Commentary: I think this PR is ready to merge . 
 Merge as " For example , on Linux platforms , the system - level TCP slow - start restart flag can be disabled { { oreilly - tcpblocks } } . " 
 From Will , 1 Idle time between  The section talks about consequences of mobile flow - bandwidth and TCP slow start , yet neither of these are relevant to the referenced NOSSDAV12 paper , which talks about a small cohort of adaptive players competing for bandwidth . The paper is a good one ( I know one of the authors ) , but the RFC section text needs to do a better job of summarizing the problems highlighted by that paper . 
 There are two issues here : First , the on - off behavior of the HTTP streaming traffic . NOSSDAV12 paper is a good reference describing that behavior and its consequences . This stuff is not explained much in the draft at the moment . I will look into this . Second , the TCP 's slow - start restart ( SSR ) " feature " . For that NOSSDAV12 was the wrong reference , it should have been MMSys11 , which I fixed for the PR . This second issue may ( or may not need further discussion ) . Can we get some feedback from CDN guys as to whether they disable SSR in production for example ? ? 
 In practice we do a number of things , including some different handling of SSR . It can be a little complicated because it can depend on what has happened in the flow , so " disabled " might not be exactly the way to think about it , and I think different settings in the config for your assets can perhaps result in different behavior . I expect also different CDNs have different answers . This text was intended to raise this as an effect to be aware of if you 're operating a server , and a point to check when you 're troubleshooting why something is not behaving as expected . I guess there might be something useful to say about CDNs and other providers that already have techniques in place to mitigate this , is that what you 're asking about here ? 
 Not commenting on a specific CDN but , as a general observation , many people tuning HTTP performance will start with something like , which includes some advice for best current practice including disabling SSR 
 Fixed in . 
 We could reasonably start with standardized mechanisms , and could also give other examples . Also provide links to specifications that provide guidance on what to measure . 
 Replace : In addition to measurements media players use to guide their segment - by - segment adaptive streaming requests , streaming media providers may also rely on measurements collected from media players to provide analytics that can be used for decisions such as whether the adaptive encoding bitrates in use are the best ones to provide to media players , or whether current media content caching is providing the best experience for viewers . With : In addition to measurements media players use to guide their segment - by - segment adaptive streaming requests , streaming media providers may also rely on measurements collected from media players to provide analytics that can be used for decisions such as whether the adaptive encoding bitrates in use are the best ones to provide to media players , or whether current media content caching is providing the best experience for viewers . To that effect , the Consumer Technology Association ( CTA ) who owns the Web Application Video Ecosystem ( WAVE ) project has published two important specifications . CTA-2066 specifies a set of media player events , properties , quality of experience ( QoE ) metrics and associated terminology for representing streaming media quality of experience across systems , media players and analytics vendors . While all these events , properties , metrics and associated terminology is used across a number of proprietary analytics and measurement solutions , they were used in slightly ( or vastly ) different ways that led to interoperability issues . CTA-2066 attempts to address this issue by defining a common terminology as well as how each metric should be computed for consistent reporting . Many assumes that the CDNs have a holistic view into the health and performance of the streaming clients . However , this is not the case . The CDNs produce millions of log lines per second across hundreds of thousands of clients and they have no concept of a " session " as a client would have , so CDNs are decoupled from the metrics the clients generate and report . A CDN can not tell which request belongs to which playback session , the duration of any media object , the bitrate , or whether any of the clients have stalled and are rebuffering or are about to stall and will rebuffer . The consequence of this decoupling is that a CDN can not prioritize delivery for when the client needs it most , prefetch content , or trigger alerts when the network itself may be underperforming . One approach to couple the CDN to the playback sessions is for the clients to communicate standardized media - relevant information to the CDNs while they are fetching data . CTA-5004 was developed exactly for this purpose . 
 CTA-2066 : CTA-5004 : 
 This should be addressed by .  , please confirm this , and let me know when we can change the reference URL for [ CTA-5004 ] . 
 URL is fixed now , so please use 
 Somehow I missed this until now- the issue is the representative bit rates in Table 1 are far too high and do not match the actual bit rate ladders that are being used to stream video in production currently .  in the doc , which I believe is based on old encoding rates is : Name  DVD 3 Mbps 720p ( 1 K ) 5 Mbps 1080p ( 2 K ) 18 Mbps 2160p ( 4k ) 70 Mbps For example - Netflix in a blog ( ) published in Aug of 2020 argues that high quality video can be done at much lower bitrates for 4 K video , but their graphs also show other resolutions . In the cited experiments they had 4 K video bitrates ranging from 8 Mbps down to 1.7Mbps with an average being 3.2 Mbps . Certainly 1080p at 1Mbps is quite commonly seen in the wild . Perhaps can reach into his academic citations and pull out a better bitrate ladder that represents actual delivery rates being used . 
 We need to find numbers that we can actually publish . 
 I will get back on this shortly . 
 is checking for a better reference :-) Need to think about whether we can / should distinguish between codecs in this material . 
 Well , here is a source we can use ( it has AVC and HEVC ): 
 Fixed in . 
 One common problem is building an ABR algorithm for low - latency delivery , especially for client - driven protocols ( ex . LL - DASH ) . Traditional segmented delivery ( HLS ) allows segments to be downloaded with unlimited throughput . It 's clear that if you can download 2s of media in 1s , then your network can handle double the throughput . Vice - versa , if it takes 3s to download 2s of media , then your network is struggling and you should switch down . But when video is delivered as it is generated ( LL - DASH ) , it is difficult to determine if your connection can handle a higher bitrate . 2s of media will be delivered in 2s even if your network can support a far higher throughput . The connection is application - limited and not congestion - limited . I have n't explored the public developments in this space , but it 's difficult enough that  has . In my opinion , it 's why LLHLS opted to use smaller segments instead of streaming segments , at the cost of higher latency . 
 That 's a good point . Groups working on real - time media protocols have historically solved this by ( 1 ) removing the need for server - side ABR when dealing with adaptation , and ( 2 ) managing the media end - to - end instead of by segments ( source -encoding -ingest -transcoding -chunking -upload -delivery .... ) . " Simulcast " is exactly the same as ABR but on the source side , removing the need for ( and the extra latency cost of ) transcoding server side . SVC codecs are one step further , since they achieve the same goal but with a single bitstream and have extra resilience , faster resolution shift , and native capacity for End - to - end encryption ( DRM on steroids to protect both content and users ) built in . I wrote a little something for non technical audience a few years back , and I m happy to give tech pointers to peer - reviewed papers and/or specifications if need be : 
 LL - HLS uses parts ( and these are not smaller segments ) just like the chunks DASH - LL uses . However , LL - HLS still has a request / response for each of these parts unlike DASH - LL and that gives them the advantage of measuring the available bw a bit easier . But then , we already have developed ways to measure the available bw accurately in DASH - LL anyway . Check the LoL+ algorithm we implemented ( and also available of as of v3.2 ) at : You might also find  's evaluation interesting : 
  to Issue 
 Fixed in . 
 It says :   - start when restarting after idle requires multiple RTTs to re - establish a throughput at the network 's available capacity . On high - RTT paths or with small enough segments , this can produce a falsely low application - visible measurement of the available network capacity . Well , TCP slow - start restart happens when TCP stays idle long enough . " Long enough " is a factor for RTT , so I do n't think slow - start restart is more likely when RTT is higher . When the segments are small , it is not more likely , either . I think what we are looking for is when the " on " duration is substantially longer than the " off " duration in the HTTP transaction . And that means , when the segment download time is substantially shorter than the inter - request time ( typically the segment duration ) , which implies download speed is far greater than the segment 's encoding bitrate . In that case , SSR will likely happen . 
 Yes , good point , thanks , the main thing is the amount of idle time . Maybe a reference to RFC 7661 is also in order , as a mitigation for senders who expect this . Not sure if the default behavior for common server systems should get a mention here as well ( and also maybe stuff like  's net.ipv4.tcpslowstartafteridle ) . 
 7661 could be mentioned as a note . I have seen some servers disabling SSR while others leaving it on by default . 
  to ( which is already addressed adequately IMO , so we can close this issue ) . 
 Fixed in . 
 The addition of LL - HLS and LL - DASH looks really good , too .
Paragraph (version A):
Height and width are in pixels, frame rate is in frames per second,
and the motion factor is a value that ranges from 20 for a low-motion
talking heads video to 7 for sports, and content with a lot of screen
changes.
Paragraph (version A):
The motion factor captures the variability in bitrate due to the
amount and frequency of high-detail motion, which generally
influences the compressability of the content.
Paragraph (version A):
The exact bitrate required for a particular video also depends on a
number of specifics about the codec used and how the codec-specific
tuning parameters are matched to the content, but this equation
provides a rough estimate that approximates the usual bitrate
characteristics using the most common codecs and settings for
production traffic.
Paragraph (version B):
Video bitrate selection depends on many variables including the
resolution (height and width), frame rate, color depth, codec,
encoding parameters, scene complexity and amount of motion.
Generally speaking, as the resolution, frame rate, color depth, scene
complexity and amount of motion increase, the encoding bitrate
increases.  As newer codecs with better compression tools are used,
the encoding bitrate decreases.  Similarly, a multi-pass encoding
generally produces better quality output compared to single-pass
encoding at the same bitrate, or delivers the same quality at a lower
bitrate.
Paragraph (version B):
Here are a few common resolutions used for video content, with
typical ranges of bitrae for the two most popular video codecs apple-
encoding.
Paragraph (version A):
Historical data shows that users consume more video and videos at
higher bitrates than they did in the past on their connected devices.
Improvements in the codecs that help with reducing 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 entertainement as
well as conversational video.
Paragraph (version B):
Historical data shows that users consume more video and videos at
higher bitrates than they did in the past on their connected devices.
Improvements in the codecs that help with reducing 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 as
well as conversational video.
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 asymetric,
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 does not, because application bandwidth usage
patterns have changed.
Paragraph (version A):
Subsequently, the Inernet Architecture Board (IAB) held a COVID-19
Network Impacts Workshop IABcovid in November 2020.  Given a larger
number of reports and more time to reflect, the following
observations from the draft workshop report are worth considering.
Paragraph (version B):
Subsequently, the Internet Architecture Board (IAB) held a COVID-19
Network Impacts Workshop IABcovid in November 2020.  Given a larger
number of reports and more time to reflect, the following
observations from the draft workshop report are worth considering.
Paragraph (version B):
Streaming media latency refers to the "glass-to-glass" time duration,
which is the delay between the real-life occurence of an event and
the streamed media being appropriately displayed on an end user's
device.  Note that this is different from the network latency
(defined as the time for a packet to cross a network from one end to
another end) because it includes video encoding/decoding and
buffering time, and for most cases also ingest to an intermediate
service such as a CDN or other video distribution service, rather
than a direct connection to an end user.
Paragraph (version B):
Ultra low-latency delivery of media is defined here as having a
glass-to-glass delay target under one second.
Paragraph (version B):
This level of latency is sometimes necessary for real-time
interactive applications such as video conferencing, operation of
remote control devices or vehicles, or remotely hosted real-time
gaming systems.  Some media content providers aim to achieve this
level of latency for live media events involving sports, but have
usually so far been unsuccessful over the internet at scale, though
it is often possible within a localized environment with a controlled
network, such as inside a specific venue connected to the event.
Applications operating in this domain that encounter transient
network events such as loss or reordering of some packets often
experience user-visible artifacts in the media.
Paragraph (version B):
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):
Most applications operating over IP networks and requiring latency
this low use the Real-time Transport Protocol (RTP) RFC3550 or WebRTC
WEBRTC, which uses RTP for the media transport as well as several
other protocols necessary for safe operation in browsers.
Paragraph (version B):
Worth noting is that many applications for ultra low-latency delivery
do not need to scale to more than one user at a time, which
simplifies many delivery considerations relative to other use cases.
For applications that need to replicate streams to multiple users,
especially at a scale exceeding tens of users, this level of latency
has historically been nearly impossible to achieve except with the
use of multicast or planned provisioning in controlled networks.
Paragraph (version B):
Recommended reading for applications adopting an RTP-based approach
also includes RFC7656.  For increasing the robustness of the playback
by implementing adaptive playout methods, refer to RFC4733 and
RFC6843.
Paragraph (version B):
Applications with further-specialized latency requirements are out of
scope for this document.
Paragraph (version B):
Low-latency live delivery of media is defined here as having a glass-
to-glass delay target under 10 seconds.
Paragraph (version B):
This level of latency is targeted to have a user experience similar
to traditional broadcast TV delivery.  A frequently cited problem
with failing to achieve this level of latency for live sporting
events is the user experience failure from having crowds within
earshot of one another who react audibly to an important play, or
from users who learn of an event in the match via some other channel,
for example social media, before it has happened on the screen
showing the sporting event.
Paragraph (version B):
Applications requiring low-latency live media delivery are generally
feasible at scale with some restrictions.  This typically requires
the use of a premium service dedicated to the delivery of live video,
and some tradeoffs may be necessary relative to what's feasible in a
higher latency service.  The tradeoffs may include higher costs, or
delivering a lower quality video, or reduced flexibility for adaptive
bitrates, or reduced flexibility for available resolutions so that
fewer devices can receive an encoding tuned for their display.  Low-
latency live delivery is also more susceptible to user-visible
disruptions due to transient network conditions than higher latency
services.
Paragraph (version B):
Implementation of a low-latency live video service can be achieved
with the use of low-latency extensions of HLS (called LL-HLS) I-
D.draft-pantos-hls-rfc8216bis-09 and DASH (called LL-DASH) LL-DASH.
These extensions use the Common Media Application Format (CMAF)
standard CMAF that allows the media to be packaged into and
transmitted in units smaller than segments, which are called chunks
in CMAF language.  This way, the latency can be decoupled from the
duration of the media segments.  Without a CMAF-like packaging, lower
latencies can only be achieved by using very short segment durations.
However, shorter segments means more frequent intra-coded frames and
that is detrimental to video encoding quality.  CMAF allows us to
still use longer segments (improving encoding quality) without
penalizing latency.
Paragraph (version B):
While an LL-HLS client retrieves each chunk with a separate HTTP GET
request, an LL-DASH client uses the chunked transfer encoding feature
of the HTTP CMAF-CTE which allows the LL-DASH client to fetch all the
chunks belonging to a segment with a single GET request.  An HTTP
server can transmit the CMAF chunks to the LL-DASH client as they
arrive from the encoder/packager.  A detailed comparison of LL-HLS
and LL-DASH is given in MMSP20.
Paragraph (version B):
Non-low-latency live delivery of media is defined here as a live
stream that does not have a latency target shorter than 10 seconds.
Paragraph (version B):
This level of latency is the historically common case for segmented
video delivery using HLS RFC8216 and DASH 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 can typically be achieved at scale with
commodity CDN services for HTTP(s) delivery, and in some cases the
increased time window can allow for production of a wider range of
encoding options relative to the requirements for a lower latency
service without the need for increasing the hardware footprint, which
can allow for wider device interoperability.
Paragraph (version B):
On-Demand media streaming refers to playback of pre-recorded media
based on a user's action.  In some cases on-demand media is produced
as a by-product of a live media production, using the same segments
as the live event, but freezing the manifest after the live event has
finished.  In other cases, on-demand media is constructed out of pre-
recorded assets with no streaming necessarily involved during the
production of the on-demand content.
Paragraph (version B):
On-demand media generally is not subject to latency concerns, but
other timing-related considerations can still be as important or even
more important to the user experience than the same considerations
with live events.  These considerations include the startup time, the
stability of the media stream's playback quality, and avoidance of
stalls and video artifacts during the playback under all but the most
severe network conditions.
Paragraph (version B):
In some applications, optimizations are available to on-demand video
that are not always available to live events, such as pre-loading the
first segment for a startup time that doesn't have to wait for a
network download to begin.
Paragraph (version A):
Many server-player systems will do an initial probe or a very simple
throughput speed test at the start of a video playback.  This is done
to get a rough sense of the highest video bit rate in the ABR ladder
that the network between the server and player will likely be able to
provide under initial network conditions.  After the initial testing,
clients tend to rely upon passive network observations and will make
use of player side statistics such as buffer fill rates to monitor
and respond to changing network conditions.
Paragraph (version B):
Many server-player systems will do an initial probe or a very simple
throughput speed test at the start of a video playback.  This is done
to get a rough sense of the highest video bitrate in the ABR ladder
that the network between the server and player will likely be able to
provide under initial network conditions.  After the initial testing,
clients tend to rely upon passive network observations and will make
use of player side statistics such as buffer fill rates to monitor
and respond to changing network conditions.
Paragraph (version A):
TCP slow-start when restarting after idle requires multiple RTTs
to re-establish a throughput at the network's available capacity.
On high-RTT paths or with small enough segments, this can produce
a falsely low application-visible measurement of the available
network capacity.
Paragraph (version A):
A detailed investigation of this phenomenon is available in
NOSSDAV12.
Paragraph (version B):
TCP slow-start when restarting after some idle time requires
multiple RTTs to re-establish a throughput at the network's
available capacity.  On high-RTT paths or with small enough
segments, this can produce a falsely low application-visible
measurement of the available network capacity.
Paragraph (version B):
How TCP slow-start restart can be avoided by the help of two
simultaneous TCP connections is exemplified for Microsoft Smooth
Streaming in MMSys11.  For some use cases, the system-level TCP slow-
start restart flag can be disabled oreilly-tcpblocks.
Paragraph (version A):
In addition to measurements media players use to guide their segment-
by-segment adaptive streaming requests, streaming media providers may
also rely on measurements collected from media players to provide
analytics that can be used for decisions such as whether the adaptive
encoding bitrates in use are the best ones to provide to media
players, or whether current media content caching is providing the
best experience for viewers.  Conviva is an example of one such such
measurement collection system in use today.
Paragraph (version B):
In addition to measurements media players use to guide their segment-
by-segment adaptive streaming requests, streaming media providers may
also rely on measurements collected from media players to provide
analytics that can be used for decisions such as whether the adaptive
encoding bitrates in use are the best ones to provide to media
players, or whether current media content caching is providing the
best experience for viewers.  Conviva is an example of one such
measurement collection system in use today.
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 B):
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):
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 B):
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 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
I-D.ietf-quic-transport as its transport layer.  QUIC relies only on
the TLS 1.3 initial handshake for key exchange I-D.ietf-quic-tls, and
encrypts almost all transport parameters, with the exception of a few
invariant fields.  In the QUIC short header, the only transport-level
parameter which is sent "in the clear" is the destination connection
ID I-D.ietf-quic-invariants.  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 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 only on the TLS 1.3
initial handshake for key exchange RFC9001, and encrypts almost all
transport parameters, with the exception of a few invariant fields.
In the QUIC short header, the only transport-level parameter which is
sent "in the clear" is the destination connection ID RFC8999.  For
these reasons, HTTP/3 is significantly more "opaque" than HTTPS with
HTTP/1 or HTTP/2.