5.  5.1. A simple model of video playback can be described as a video stream workflows are introduced. The challenges in filling the buffer in a timely way fall into two <del> broad categories: 1. content selection and 2. content variation. Content selection comprises all of the steps needed to determine which content variation to offer the client.  Content variation is the number of content options that exist at any given selection point.  A common example, easily visualized, is Adaptive BitRate (ABR), described in more detail below.  The mechanism used to select the bitrate is part of the content selection, and the content variation are all of the different bitrate renditions. ABR is a sort of application-level response strategy in which the </del>  streaming client attempts to detect the available bandwidth of the <del> 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.). </del>  5.2. adaptive streaming requests, but may also provide measurements to streaming media providers. <del> In turn, providers may base analytics on these measurements, to guide decisions such as whether adaptive encoding bitrates in use are the best ones to provide to media players, or whether current media </del>  content caching is providing the best experience for viewers. To that effect, the Consumer Technology Association (CTA), who owns

and provide context.
This seems out of place here to me, but I can see why it's hard to find a spot for the AQM reference since we don't have anything else that talks about network latency. Hmm, how badly do we think we need this?
We like part of one sentence in this PR, that we think does belong in the document, but we aren't sure it belongs where it is in the document.
NAME and NAME - I note that in , NAME asked about mentioning active testing in Section 5. Although the lightning talk NAME gave was describing an active testing system Comcast had deployed to monitor their access networks, and we've agreed that the underlying network was a "black box" from the perspective of media providers, ISTM that over-the-top media providers could perform active testing as well, between their origin servers and the first downstream media receivers (whether that is a CDN or endpoint media players), in order to detect significant changes in performance for a known workflow. I plan to add a mention of active testing in Section 5 as part of this PR, referencing Jason's lightning talk, rather than trying to use the lightning talk in two parallel PRs.
I agree this is possible in theory, but I'm not aware of any operational experience that's been collected on these techniques. NAME I don't suppose you have a reference to work that describes using active measurements to improve media streaming delivery?
was this added?.. NAME what you wrote here is inline with my thinking. However, this document is also supposed to provide information for network administrators. Hence, I believe it would be good to cover the active testing , i.e. a summery of what you wrote would be necessary. I will also note that, there are system designed to provide QoE/QoS information to a network node from the application (URL). This is to help the network operators to fine tune their part of delivery of the e2e chain. This is not active testing, however, this puts network operators on the perspective of media quality. what is the view regarding this?
Jason Livingood's presentation is at URL - mention experience with DOCSIS 3.1 AQM?
Not sure this fits in the document, but someone should be looking at this who is awake (and we were not awake by TSVAREA at the last IETF 111 meeting slot). Jake anecdote about WebEx conversation where speech was noticeably buffered and then suddenly released in a burst. Might be worth adding a comment in passing that there are many sources of jitter and buffering - can't get lower latency than the network can give you.
This is on my list ...
NAME I couldn't think of a way to describe advantages of active testing that would work better than the measurement collection section for streaming media operators. Sure, active measurements can be the right thing to do, for operators providing access networks, etc. - that's what NAME was talking about in his lightning talk. But I did take an opportunity to clean up the abr introduction, so there's that ...
lgtm

5. <ins> This section describes one of the best known ways to provide a good user experience over a given network path, but one thing to keep in mind is that application-level mechanisms cannot provide a better experience than the underlying network path can support. </ins> 5.1. A simple model of video playback can be described as a video stream workflows are introduced. The challenges in filling the buffer in a timely way fall into two  <ins> broad categories: Content selection comprises all of the steps needed to determine which content variation to offer the client. Content variation is the number of content options that exist at any given selection point. The mechanism used to select the bitrate is part of the content selection, and the content variation are all of the different bitrate renditions. Adaptive bitrate streaming ("ABR streaming", or simply "ABR") is a commonly used technique for dynamically adjusting the compression level and video quality of a stream to match bandwidth availability. When this goal is achieved, the media server will tend to send enough media that the media player does not "stall", without sending so much media that the media player cannot accept it without exhausting all available receive buffers. ABR uses an application-level response strategy in which the </ins> streaming client attempts to detect the available bandwidth of the  <ins> network path by first observing the successful application-layer download speed, and then, given the available bandwidth, the client chooses a bitrate for each of the video, audio, subtitles and metadata (among a limited number of available options for each type of media) 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.). </ins> 5.2. adaptive streaming requests, but may also provide measurements to streaming media providers.  <ins> In turn, media providers may base analytics on these measurements, to guide decisions such as whether adaptive encoding bitrates in use are the best ones to provide to media players, or whether current media </ins> content caching is providing the best experience for viewers. To that effect, the Consumer Technology Association (CTA), who owns


caches. Various HTTP versions have been used for media delivery.  HTTP/1.0, <del> 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. </del>  Unreliable media delivery using RTP and other UDP-based protocols is also discussed in ultralow, unreliable-behavior, and hop-by-hop- RTP RFC3550, which can notice packetloss and repair some limited reordering, <del> SCTP RFC4960, which can use partial reliability RFC3758 to recover </del>  from some loss, but can abandon recovery to limit head-of-line blocking, and

lgtm
From NAME
Done, except that 4960bis has now popped out as RFC9260. For these next two comments - our responses to reviews from NAME and NAME especially in dropping a lot of the archeology text about TCP, focusing on transport services, and working to make sure we are comparing apples to apples (2022 TCP to 2022 QUIC), have significantly improved the document throughout Section 6. The new discussion of "typically implemented in a kernel, although it doesn't have to be" and "typically implemented in userspace, although it doesn't have to be" is also intended to be more even-handed than the original text. I'm still following up on a couple of things with NAME and NAME but -11 will be significantly better, thanks to the review teams.

caches. Various HTTP versions have been used for media delivery.  HTTP/1.0,  <ins> HTTP/1.1 and HTTP/2 are carried over TCP I-D.ietf-tcpm-rfc793bis, 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. </ins> Unreliable media delivery using RTP and other UDP-based protocols is also discussed in ultralow, unreliable-behavior, and hop-by-hop- RTP RFC3550, which can notice packetloss and repair some limited reordering,  <ins> SCTP RFC9260, which can use partial reliability RFC3758 to recover </ins> from some loss, but can abandon recovery to limit head-of-line blocking, and


5.5.2. <del> In the event of a lost packet on a TCP connection with SACK support (a common case for segmented delivery in practice), loss of a packet can provide a confusing bandwidth signal to the receiving </del>  application.  Because of the sliding window in TCP, many packets may be accepted by the receiver without being available to the application until the missing packet arrives.  Upon the arrival of get access to a lot of data at the same time. To a receiver measuring bytes received per unit time at the <del> application layer, and interpreting it as an estimate of the available network bandwidth, this appears as a high jitter in the goodput measurement, presenting as a stall, followed by a sudden leap that can far exceed the actual capacity of the transport path from the server when the hole in the received data is filled by a later </del>  retransmission. <del> It is worth noting that more modern transport protocols such as QUIC have mitigation of head-of-line blocking as a protocol design goal. See quic-behavior for more details. </del> 5.5.3. As many end devices have moved to wireless connections for the final high-bandwidth traffic such as streaming media over the UDP ports that HTTP/3 is using. <del> As noted in hol-blocking, because TCP provides a reliable, in-order delivery service for applications, any packet loss for a TCP </del>  connection causes head-of-line blocking, so that no TCP segments arriving after a packet is lost will be delivered to the receiving application until retransmission of the lost packet has been

attempted fix for --the section is saying noisy measurements are a concern, not that head of line blocking per se is a concern.
From NAME 's review (URL) 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).
Also mentioned in section 6.3 about QUIC.
NAME 'said benefit from backing by a reference.
Fig. 1 from URL
Change the section title for 5.5.2: it's not really about head-of-line blocking specifically, it's about a noisy goodput signal when measuring data received at the application layer, which requires appropriate smoothing in the player's bitrate detection algorithm.
The text in 6.3 isn't about head-of-line blocking, either.
Discussion on editor conference call: we really like the diagram Ali provided ... Reviewer: Michael Scharf 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 EMAIL 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 don'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. Recognizing Changes 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 Wifi and 4G/5G networks in one place. Some of this follows later in sections 3.2.1 and 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 Ethernet Switch, a Wifi 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. Ultra Low-Latency 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 added 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, 5G, 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 Wifi connectivity and no Ethernet port, i.e., Wifi 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. TCP 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 apps other than circuit breakers? (I am thinking about 4K 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

5.5.2.  <ins> In addition to smoothing over an appropriate time scale to handle network jitter (see RFC5481), ABR systems relying on measurements at the application layer also have to account for noise from the in- order data transmission at the transport layer. For instance, in the event of a lost packet on a TCP connection with SACK support (a common case for segmented delivery in practice), loss of a packet can provide a confusing bandwidth signal to the receiving </ins> application.  Because of the sliding window in TCP, many packets may be accepted by the receiver without being available to the application until the missing packet arrives.  Upon the arrival of get access to a lot of data at the same time. To a receiver measuring bytes received per unit time at the  <ins> application layer and interpreting it as an estimate of the available network bandwidth, this appears as a high jitter in the goodput measurement, presenting as a stall followed by a sudden leap that can far exceed the actual capacity of the transport path from the server when the hole in the received data is filled by a later </ins> retransmission.  5.5.3. As many end devices have moved to wireless connections for the final high-bandwidth traffic such as streaming media over the UDP ports that HTTP/3 is using.  <ins> As noted in noisy-measurements, because TCP provides a reliable, in- order delivery service for applications, any packet loss for a TCP </ins> connection causes head-of-line blocking, so that no TCP segments arriving after a packet is lost will be delivered to the receiving application until retransmission of the lost packet has been


Even when the bandwidth requirements for video streams along a path are well understood, additional analysis is required to understand <del> the constraints on bandwidth at various points in the network.  This analysis is necessary because media servers may react to bandwidth constraints using two independent feedback loops: </del>  Media servers often respond to application-level feedback from the media player that indicates a bottleneck somewhere along the path In one example, if a media server overestimates the available bandwidth to the media player, <del> the transport protocol detects loss due to congestion and reduces its sending window size per round trip, </del>  the media server adapts to application-level feedback from the media player and reduces its own sending rate, probing. To avoid these types of situations, which can potentially affect all <del> the users whose streaming media segments traverse a bottleneck, there are several possible mitigations that streaming operators can use. However, the first step toward mitigating a problem is knowing that a problem is occurring. </del>  3.2.1.

From NAME -
NAME - after thinking about this comment, I think two things need to happen - your observation about bottlenecks at different nodes/hops/layers of the protocol stack belongs at the beginning of this section, because we're drilling down on ONE layer of the protocol stack in the rest of section 3.2, and as you say, the reference to "link" is not helpful here. Please let me know if URL is responsive to this comment.

Even when the bandwidth requirements for video streams along a path are well understood, additional analysis is required to understand  <ins> the constraints on bandwidth at various points along the path between media servers and media players.  Video streams can encounter bottlenecks at many points along a path, whether the bottleneck happens at a node or at a path segment along the path, and these bottlenecks may involve a lack of processing power, buffering capacity, link speed, or any other exhaustible resource. Media servers may react to bandwidth constraints using two independent feedback loops: </ins> Media servers often respond to application-level feedback from the media player that indicates a bottleneck somewhere along the path In one example, if a media server overestimates the available bandwidth to the media player,  <ins> the transport protocol may detect loss due to congestion and reduce its sending window size per round trip, </ins> the media server adapts to application-level feedback from the media player and reduces its own sending rate, probing. To avoid these types of situations, which can potentially affect all  <ins> the users whose streaming media segments traverse a bottleneck path segment, there are several possible mitigations that streaming operators can use.  However, the first step toward mitigating a problem is knowing that a problem is occurring. </ins> 3.2.1.


networking practices and observations of media delivery issues encountered when streaming media over those existing networks. <del> This document defines "high-bitrate streaming media" as follows: </del>  "High-bitrate" is a context-sensitive term broadly intended to capture rates that can be sustained over some but not all of the "Media" refers to any type of media and associated streams such as video, audio, metadata, etc. <del> 1.1. </del>  A full review of all streaming media considerations for all types of media over all types of network paths is too broad a topic to cover of reference for future solution proposals to describe how new technologies address or avoid existing problems. <del> generalized network performance techniques; while things like datacenter design and transit network design can be crucial dependencies for a performant streaming media service, these are considered independent topics better addressed by other documents. </del>  transparent tunnels; while tunnels can have an impact on streaming media via issues like the round-trip time and the maximum difficult to give general guidance for unreliable media transport protocols used to carry interactive real-time media. <del> 1.2. </del>  Note to RFC Editor: Please remove this section and its subsections before publication. This section is to provide references to make it easier to review the development and discussion on the draft so far. <del> 1.2.1. </del>  This document is in the GitHub repository at: services. Implementation of a low-latency live video service can be achieved <del> with the use of low-latency extensions of HLS (called LL-HLS) I- D.draft-pantos-hls-rfc8216bis and DASH (called LL-DASH) LL-DASH. These extensions use the Common Media Application Format (CMAF) standard MPEG-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, using shorter segments means using 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. </del>  While an LL-HLS client retrieves each chunk with a separate HTTP GET request, an LL-DASH client uses the chunked transfer encoding feature seconds. This level of latency is the historically common case for segmented <del> video delivery using HLS RFC8216 and DASH MPEG-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. </del>  This level of latency can typically be achieved at scale with commodity CDN services for HTTP(s) delivery, and in some cases, the consumer, a buffer, and a transport mechanism that fills the buffer. The consumption rate is fairly static and is represented by the content bitrate.  The size of the buffer is also commonly a fixed <del> size.  The fill process needs to be at least fast enough to ensure that the buffer is never empty, however, it also can have significant complexity when things like personalization or advertising insertion workflows are introduced. </del>  The challenges in filling the buffer in a timely way fall into two broad categories: 5.3. <del> ABR playback is commonly implemented by streaming clients using HLS RFC8216 or DASH MPEG-DASH to perform a reliable segmented delivery of media over HTTP.  Different implementations use different strategies ABRSurvey, often relying on proprietary algorithms (called rate adaptation or bitrate selection algorithms) to perform available bandwidth estimation/prediction and the bitrate selection. </del>  Many systems will do an initial probe or a very simple throughput speed test at the start of video playback.  This is done to get a

Also move some expansions and references to first use.
From NAME -
Hi, NAME - We've been focused on what endpoints could do to improve streaming media performance, but it does seem helpful to point that out more clearly. Please see if is helpful.

networking practices and observations of media delivery issues encountered when streaming media over those existing networks.  <ins> 1.1. This document defines "high-bitrate streaming media over the Internet" as follows: </ins> "High-bitrate" is a context-sensitive term broadly intended to capture rates that can be sustained over some but not all of the "Media" refers to any type of media and associated streams such as video, audio, metadata, etc.  <ins> "Over the Internet" means that a single operator does not have control of the entire path between media servers and media clients, so not a "walled garden". 1.2. </ins> A full review of all streaming media considerations for all types of media over all types of network paths is too broad a topic to cover of reference for future solution proposals to describe how new technologies address or avoid existing problems.  <ins> generalized network performance techniques; while considerations such as datacenter design, transit network design, and "walled garden" optimizations can be crucial components of a performant streaming media service, these are considered independent topics better addressed by other documents. </ins> transparent tunnels; while tunnels can have an impact on streaming media via issues like the round-trip time and the maximum difficult to give general guidance for unreliable media transport protocols used to carry interactive real-time media.  <ins> 1.3. </ins> Note to RFC Editor: Please remove this section and its subsections before publication. This section is to provide references to make it easier to review the development and discussion on the draft so far.  <ins> 1.3.1. </ins> This document is in the GitHub repository at: services. Implementation of a low-latency live video service can be achieved  <ins> with the use of "HTTP Live Streaming (HLS)" RFC8216 by using its low- latency extension (called LL-HLS) I-D.draft-pantos-hls-rfc8216bis or with "Dynamic Adaptive Streaming over HTTP (DASH)" MPEG-DASH by using its low-latency extension (called LL-DASH) LL-DASH.  These extensions use the Common Media Application Format (CMAF) standard MPEG-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, using shorter segments means using 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. </ins> While an LL-HLS client retrieves each chunk with a separate HTTP GET request, an LL-DASH client uses the chunked transfer encoding feature seconds. This level of latency is the historically common case for segmented  <ins> video 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. </ins> This level of latency can typically be achieved at scale with commodity CDN services for HTTP(s) delivery, and in some cases, the consumer, a buffer, and a transport mechanism that fills the buffer. The consumption rate is fairly static and is represented by the content bitrate.  The size of the buffer is also commonly a fixed  <ins> size.  The buffer fill process needs to be at least fast enough to ensure that the buffer is never empty, however, it also can have significant complexity when things like personalization or advertising insertion workflows are introduced. </ins> The challenges in filling the buffer in a timely way fall into two broad categories: 5.3.  <ins> Adaptive Segmented Delivery attempts to optimize its own use of the path between a media server and a media client.  ABR playback is commonly implemented by streaming clients using HLS RFC8216 or DASH MPEG-DASH to perform a reliable segmented delivery of media over HTTP.  Different implementations use different strategies ABRSurvey, often relying on proprietary algorithms (called rate adaptation or bitrate selection algorithms) to perform available bandwidth estimation/prediction and the bitrate selection. </ins> Many systems will do an initial probe or a very simple throughput speed test at the start of video playback.  This is done to get a


the set of network path properties. It is worth pointing out explicitly because questions about "Web <del> Real-Time Communication (WebRTC)" has come up often, that some WebRTC protocols (RFC8834, RFC8835) are mentioned in this document, including RTP, WebRTC's principal media transport protocol.  However, (as noted in sd) it is difficult to give general guidance for unreliable media transport protocols used to carry interactive real- time media. </del>  1.2. bandwidth" between streaming video servers and streaming video receivers into account when encoding because the codec does not have any idea what network paths and network path conditions will <del> carry the encoded video at some point in the future. </del>  Note that video receivers attempting to receive encoded video across a network path with insufficient available path bandwidth might request the video server to provide video encoded for lower <del> bitrates, as described in adapt-deliver. </del>  In order to provide multiple encodings for video resources, the codec must produce multiple versions of the video resource encoded transmission, so the transport protocol cannot probe for available path bandwidth <del> by sending at a higher rate until the media receiver signals the media server that the media server can increase its media segment sending rate. </del>  To avoid these types of situations, which can potentially affect all the users whose streaming media segments traverse a bottleneck, there

NAME - I went back through -11 and made sure we had at least tried to address each of your comments. Thank you for the careful read.
From NAME
NAME thank you for the review. On a quick read (the authors have a conference call this afternoon my time), most of these are immediately actionable, and the ones that need a bit more discussion seem helpful and worth discussing. More news to follow, of course.
NAME and NAME - NAME review has popped up some higher-level questions for me, that could be addressed in this issue, or in separate issues. I'm keeping this list here, until our call in about 26 minutes. This document uses the word "media" about 200 times, and the word "video" about 70 times. I know I haven't been careful to use the best word in text I've written. It's probably worth doing a pass in the document to make sure that we say what we mean. Actually, are we mostly talking about "media" in general, and only mentioning "video" in specifics? We only use the qualifier "high-bitrate" three times (and two of these are in the abstract and introduction). That seems like an important qualifier. I think this document does include Video On Demand. Does anyone disagree? We've been saying that media delivery over RTP is "out of scope", but the word "RTP" appears 12 times in the document. I think we're including "interactive", "live", and "VoD" streaming media, and we probably need to say that clearly, early in the document. is there any difference, from the media provider's perspective, if (presumably high-bitrate) media is streamed to be consumed by a machine? Zahed has an excellent question - can we explain what's different about ads, in about 1/4 the space? sometimes we say "content provider", and other times we say "media provider". Is there a meaningful difference, or can we use the same term? I'm surprised that we only use the term "operator" three times, and even more surprised that these aren't all talking about the same thing, so that needs to be fixed ...
NAME and NAME - I'm working through the high-level questions in my previous comment, and I have a few new ones. We never defined "high-bitrate", although we (now) use the term in the abstract and in the Introduction. I'm thinking about adding a pointer to the table of typical bitrates for various bitrates and resolutions in the "Video Bitrates" section, and saying "like, these bitrates".
NAME and NAME - NAME reasonably asked about a citation for this assertion in the draft: After poking around for a while, I'm not seeing an obvious citation in open literature (indexed by Google), specific to 5G. We do need to decide what to do with this one comment, before merging .
I probably wrote that text, and the reason I believed it was that it was discussed in I think a tsvwg or iccrg session talking about using chirping experimentally in conjunction with TCP Prague to find the link capacity, I think either by Ingemar or Bob. I now wish I could recall which meeting, or even which year I saw this. I don't have a straight capacity metric, but I saw some stuff about attenuation and effects like shadow fading and path loss that I think are the physics reasons behind the 2nd-hand reported observation: URL URL Maybe we should strike the claim if we can't find a good source for it--these 5g docs talking about the relevant effects tend to speak in decibels rather than mbps, and it's not clear to me exactly how they translate.
NAME - I'd be astounded if no one at the IETF could speak to this, but in the references I could find, ISTM that there are all kinds of things that can affect pretty much any path traversing at least one wireless link. I removed the specific 5G and LTE likewise can easily see rate variation by a factor of 2 or more over a span of seconds as users move around., which I don't think we can back up precisely, so now all the wireless-link paths are covered by an overarching In most real-world operating environments, wireless links can often experience sudden changes in capacity as the end user device moves from place to place or encounters new sources of interference. If that works for you, should be ready to review and (if it's OK) merge.
NAME on this comment, (as an aside, I should mention that I don't have any memory of active measurements being discussed in the working group for this document, but let's ignore that, for now, and try to do the right thing) I couldn't think of a way to describe advantages of active testing that would work better than the measurement collection section for streaming media operators. Sure, active measurements can be the right thing to do, for operators providing access networks, etc.

the set of network path properties. It is worth pointing out explicitly because questions about "Web  <ins> Real-Time Communication (WebRTC)" has come up often, that RTP, WebRTC's principal media transport protocol (RFC8834, RFC8835), is mentioned in this document.  However, (as noted in sd) it is difficult to give general guidance for unreliable media transport protocols used to carry interactive real-time media. </ins> 1.2. bandwidth" between streaming video servers and streaming video receivers into account when encoding because the codec does not have any idea what network paths and network path conditions will  <ins> carry the encoded video at some point in the future.  It is common for codecs to offer a small number of resource variants, differing only in the bandwidth each variant targets. </ins> Note that video receivers attempting to receive encoded video across a network path with insufficient available path bandwidth might request the video server to provide video encoded for lower  <ins> bitrates, at the cost of lower video quality, as described in adapt-deliver. </ins> In order to provide multiple encodings for video resources, the codec must produce multiple versions of the video resource encoded transmission, so the transport protocol cannot probe for available path bandwidth  <ins> by sending at a higher rate until the media receiver requests segments that buffer enough data for the transport to perform the probing. </ins> To avoid these types of situations, which can potentially affect all the users whose streaming media segments traverse a bottleneck, there


to-glass delay target under 10 seconds. This level of latency is targeted to have a user experience similar <del> 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. </del>  Applications requiring low-latency live media delivery are generally feasible at scale with some restrictions.  This typically requires 4.3. <del> 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. </del>  This level of latency is the historically common case for segmented video delivery using HLS RFC8216 and DASH MPEG-DASH.  This level of

From NAME
NAME - thank you for this review. You caught a lot more things than I was hoping were still in there. :grinning:
PR should address these issues (and more).
Agree with NAME that this fixed lots of stuff. I'd like to leave it open so we can run this tool again after addressing more issues.

to-glass delay target under 10 seconds. This level of latency is targeted to have a user experience similar  <ins> to 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. </ins> Applications requiring low-latency live media delivery are generally feasible at scale with some restrictions.  This typically requires 4.3.  <ins> Non-low-latency live delivery of media is defined here as a livestream that does not have a latency target shorter than 10 seconds. </ins> This level of latency is the historically common case for segmented video delivery using HLS RFC8216 and DASH MPEG-DASH.  This level of


IETF 106 meeting: https://www.youtube.com/watch?v=4_k340xT2jM&t=7m23s  2. 2.1.

I assume this is uncontroversial and am therefore just merging it, hearing no objections.

IETF 106 meeting: https://www.youtube.com/watch?v=4_k340xT2jM&t=7m23s <ins> MOPS Interim Meeting 2020-04-15: https://www.youtube.com/watch?v=QExiajdC0IY&t=10m25s IETF 108 meeting: https://www.youtube.com/watch?v=ZaRsk0y3O9k&t=2m48s </ins> 2. 2.1.


2.3. <del> TBD: pros, cons, tradeoffs of caching designs at different locations within the network? Peak vs. average provisioning, and effects on peering point congestion under peak load? Provisioning issues for caching systems? </del>  2.4. 2.6. <del> The causes of unpredictable usage described in sec-unpredictable were </del>  more or less the result of human choices, but we were reminded during a post-IETF 107 meeting that humans are not always in control, and forces of nature can cause enormous fluctuations in traffic patterns.

This is against issue 13.
Do we need anything in here about cache footprint considerations with fragmented MP4 vs. older style ts segments in multiple formats? Could be done as a separate update, but it seems possibly relevant here.
Hearing no other objections, I'll merge this. I'll leave cache footprint fmp4 considerations as a possibility for future prs and resolve this.
NAME had what I think is an excellent suggestion of one line per sentence: URL I've seen other docs use one line per paragraph, which I attempted to use in a recent commit but I kind of hate. Regardless, we should make a whitespace-only pass through the doc and make it all the same. I vote for one line per sentence. (I assume this would not include text inside bullet points and tables--not sure if there's a section of a doc somewhere about the pros and cons of different approaches?)
I'm happy to make a formatting pass and check what kramdown, etc. does with it. Do we want to land the changes in URL first, or reformat first and rebase your PR?
I guess I'm voting for land the changes first and do a whitespace format when we won't have conflicts. Should be pretty quick, right?
(*note, there is another pull request also that would be affected if we do it now: URL )
Closing, don't need to fix this (not expecting many more PRs anyway).
Pulling the TBD out of the draft text and capturing it here instead. Suggestion from mic at IETF 106 (Dave Oran + Glenn Deen responding): Pre-placement for many use cases is useful--distinguish between live vs. cacheable. "People assume high-demand == live, but not always true" with popular netflix example. Pre-placement in caches can ameliorate high-bandwidth needs without having to use e.g. multicast. Explain where it's applicable and not, and what the constraints are. URL (This probably goes in the caching section as that's written.)
+Glenn's comment: also capture latency constraints as a usability/qos part for live+popular vs. pre-recorded and expected-popular.
I would like to think that PR 30 is a start here ...
was merged, but this issue wasn't closed. Closing now ...

2.3.  <ins> 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. It is worth noting that not all high-demand content is also "live" content.  One popular example is when popular streaming content can be staged close to a significant number of requesters, as can happen when a new episode of a popular show is released.  This content may be largely stable, so low-cost to maintain in multiple places throughout the Internet.  This can reduce demands for high end-to-end bandwidth without having to use mechanisms like multicast. 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, and could be pre-loaded during off-peak hours, using "Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services" RFC8622, "Low Extra Delay Background Transport (LEDBAT)" RFC6817, or similar mechanisms. All of this depends, of course, on the ability of a content 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, sec-extreme). </ins> 2.4. 2.6.  <ins> The causes of unpredictable usage described in sec-unpredict were </ins> more or less the result of human choices, but we were reminded during a post-IETF 107 meeting that humans are not always in control, and forces of nature can cause enormous fluctuations in traffic patterns.


Operational Considerations for Streaming Media <del> draft-ietf-mops-streaming-opcons-03 </del>  Abstract IETF 108 meeting: https://www.youtube.com/watch?v=ZaRsk0y3O9k&t=2m48s  2. 2.1. Comcast's streaming and web video consumption rose by 38%, with their reported peak traffic up 32% overall between March 1 to <del> March 30 Comcast, </del>  AT&T reported a 28% jump in core network traffic (single day in April, as compared to pre stay-at-home daily average traffic), with video accounting for nearly half of all mobile network traffic, while social networking and web browsing remained the highest percentage (almost a quarter each) of overall mobility <del> traffic ATT, and </del>  Verizon reported similar trends with video traffic up 36% over an <del> average day (pre COVID-19) Verizon. </del>  We note that other operators saw similar spikes during this time period.  Craig Labowitz Labovitz reported this increase to the significant rise in gaming-related DDoS attacks (LabovitzDDoS), as gaming usage also increased.)  3. 3.1.

…nd update public discussion venues
I left the previous description of Sanjay Mishra's presentation, but removed the sub-references in that description (which included the problematic ATT reference).
We should try to improve this reference - it's a long page, additions are at the top, so we have to either scroll for a long time or search for the date to get the relevant part of the page. Maybe reach out to ATT to get fragment tags that work?

Operational Considerations for Streaming Media  <ins> draft-ietf-mops-streaming-opcons-latest </ins> Abstract IETF 108 meeting: https://www.youtube.com/watch?v=ZaRsk0y3O9k&t=2m48s <ins> MOPS 2020-10-30 Interim meeting: https://www.youtube.com/watch?v=vDZKspv4LXw&t=17m15s </ins> 2. 2.1. Comcast's streaming and web video consumption rose by 38%, with their reported peak traffic up 32% overall between March 1 to  <ins> March 30, </ins> AT&T reported a 28% jump in core network traffic (single day in April, as compared to pre stay-at-home daily average traffic), with video accounting for nearly half of all mobile network traffic, while social networking and web browsing remained the highest percentage (almost a quarter each) of overall mobility  <ins> traffic, and </ins> Verizon reported similar trends with video traffic up 36% over an  <ins> average day (pre COVID-19)}. </ins> We note that other operators saw similar spikes during this time period.  Craig Labowitz Labovitz reported this increase to the significant rise in gaming-related DDoS attacks (LabovitzDDoS), as gaming usage also increased.) <ins> 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. Participants describing different types of networks reported different kinds of impacts, but all types of networks saw impacts. Mobile networks saw traffic reductions and residential networks saw significant increases. 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. At DE-CIX Frankfurt, the world's largest Internet Exchange Point in terms of data throughput, the year 2020 has seen the largest increase in peak traffic within a single year since the IXP was founded in 1995. The usage pattern changed significantly as work-from-home and videoconferencing usage peaked during normal work hours, which would have typically been off-peak hours with adults at work and children at school.  One might expect that the peak would have had more impact on networks if it had happened during typical evening peak hours for video streaming applications. 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. At the IXP-level, it was observed that port utilization increased. This phenomenon is mostly explained by a higher traffic demand from residential users. </ins> 3. 3.1.


4. <del> This document requires no actions from IANA. </del>  5.  This document introduces no new security issues.

I think the separation between hop-by-hop vs. transport is useful. Do we need to say something about privacy and/or pervasive monitoring and point out that end-to-end encryption has one set of properties and hop-by-hop media encryption has a different set of properties?
NAME I am talking about privacy and pervasive monitoring now. See what you think on my next commit.
I did receive a private email from NAME pointing out that repeated encryption of the same content can lessen the protection of encryption against pervasive monitoring. I've added text about that, but also asked Glenn if he could provide a reference that I could include. Other than that, I think this PR is ready to merge. NAME or NAME any objections?
LGTM, go for it
This should be discussed in the following contexts: 1) Content owners feel more secure when their contents are encrypted at every level (at the transport/http level in addition to the application level, DRM, etc.). 2) E2E encryption is becoming more prevailing as the streaming service providers also do not want to be messed by the network service providers any more. a) Network service providers should not mess with manifests, requests, media, etc. This is unlawful for many reasons. b) Network service providers should rather co-operate with the streaming service providers to enhance the user experience as well as better utilize the network resources. See server and network assisted DASH, part 5 of the DASH standard (URL)
I'm not sure the feelings of the content owners can be generalized cleanly, but I agree it might make sense to talk about the security (and privacy) characteristics of the available encryption approaches that can be applied at different layers, as well as the trends in the use of encryption. That seems like a good point. I'm a little worried this is a can of worms that might be better as a separate document, because I think it gets quite complicated if we end up trying to explain the security properties, the threat models, and the challenges in guarding against the threat models, and far more so if that pulls us toward touching on anything potentially controversial. But I agree there's probably something useful to say about encryption with regard to operational considerations for media streaming, and that it can likely be a useful section if we can keep the scope constrained.
I believe there are many resources in terms of e2eme (m => media) that could be listed to give a good overview, without going too much int the details. DRM model for media, as used in conjunction with MPEG-DASH and HLS, and used by the W3C are one (URL), the work of the PERC working group for RTP over UDP/TCP is another one (URL), QUIC is yet another one that would come naturally to mind first.
and recent work on e2ee for media over internet: IETF Frame Working group, and corresponding first draft: URL
I'm thinking I should take this one, especially with NAME suggestions. I'll probably downsize that specifically to streaming media, so leaving RTP-based techniques out (at least for now), but this looks super do-able.
Hi spencer, Note that SFrame, unlike it's predecessor PERC which is RTP specific, has been designed to be Media Transport agnostic as we wanted to be able to use RTP or e.g. QUIC. This design was made consciously, as threat models are always use case specific, and we wanted to extract the media encryption itself, which is common to the video conferencing use case and the streaming use case for example. One hope is that this could be used in conjunction to existing DRM facilities (KMS, ...) to extend DRM (in browsers) to the real-time use case, and also to cover the entire media path and not just the delivery part like DRM does today. The SFrame draft itself describes only the media encryption, while other documents, for now external to the SFrame working group, describe key exchange with MLS in the video conferencing use case (Cisco), or the RTP use case specifically (Part of AVTCORE scope). It is being designed to be compatible with SVC codecs extension for RTP (AVTCORE), and new proposal for WebRTC's ingest signalling (WISH). Let me know if you want some help in the matter, if only to point you to ongoing effort within IETF to get the big picture.
This will heavily point to the impact on increased end-to-end encryption on network operators. RTCWeb (RFC 8825) has a section on this, as does QUIC Manageability. Make sure we describe what happens if manifests are encrypted - operators that lower the offered quality to reduce impact on their networks can't do that any more. Also true for analytics/feedback hijacking. Find and reference a public discussion (Netflix, someone in MOPS may be able to provide this).
NAME check this out: URL

4.  <ins> "Encrypted Media" has at least three meanings: Media encrypted at the application layer, typically using some sort of Digital Rights Management (DRM) system, and typically retaining this encryption "at rest", when it is stored at senders and receivers, Media encrypted by the sender at the transport layer, and remaining encrypted until it reaches the ultimate media consumer (in this document, referred to as "end-to-end media encryption"), and 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 descryption 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") Both "hop-by-hop" and "end-to-end" encrypted transport may carry media that is, in addition, encrypted at the application layer. Each of these encryption strategies is intended to achieve a different goal.  For instance, application-level encryption may be used for business purposes, such as avoiding piracy or enforcing geographic restrictions on playback, while transport-layer encryption may be used to prevent media steam manipulation or to protect manifests.  This document does not take a position on whether those goals are "valid" (whatever that might mean). In this document, we will focus on media encrypted at the transport layer, whether encrypted "hop-by-hop" or "end-to-end". Both "End-to-End" and "Hop-by-Hop" media encryption have implications for streaming operators. 4.1. 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. codaspy 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 breaks privacy as certainly as examining decrypted traffic. 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. 4.2. Although the IETF has put considerable emphasis on end-to-end streaming media encryption, there are still important use cases that require the insertion of intermediaries. There are a variety of ways to involve intermediaries, and some are much more intrusive than others. From a content provider's perspective, a number of considerations are in play.  The first question is likely whether the content provider intends that intermediaries are explicitly addressed from endpoints, or whether the content provider is willing to allow intermediaries to "intercept" streaming content transparently, with no awareness or permission from either endpoint. If a content 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. Assuming that a content provider does intend to allow intermediaries to participate in content streaming, and does intend to provide some level of privacy for endpoints, there are a number of possible tools, either already available or still being specified.  These include Server And Network assisted DASH 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. "Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP)" RFC8723 - this specification provides a cryptographic transform for the Secure Real-time Transport Protocol that provides both hop-by-hop and end-to-end security guarantees. 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. If a content provider chooses not to involve intermediaries, this choice should be carefully considered.  As an example, if media manifests are encrypted end-to-end, network providers who had been able to lower offered quality and reduce on their networks will no longer be able to do that.  Some resources that might inform this consideration are in RFC8825 (for WebRTC) and I-D.ietf-quic- manageability (for HTTP/3 and QUIC). 4.3. "End-to-end" media encryption offers the potential of providing privacy for streaming media consumers, with the idea being that if an unauthorized intermediary can't decrypt streaming media, the intermediary can't use Deep Packet Inspection (DPI) to examine HTTP request and response headers and identify the media content being streamed. "End-to-end" media encryption became much more widespread in the years since RFC7258 was issued, which identified pervasive monitoring as a much greater threat than previously appreciated.  After the Snowden disclosures, many content providers made the decision to use HTTPS protection - HTTP over TLS - for most or all content being delivered as a routine practice, rather than in exceptional cases for content that was considered "sensitive". </ins> 5. <ins> This document requires no actions from IANA. 6. </ins> This document introduces no new security issues.


Abstract This document provides an overview of operational networking issues <del> that pertain to quality of experience in delivery of video and other </del>  high-bitrate media over the internet. 1. compound annual growth rate continuing at 34% (from Appendix D of CVNI).  In many contexts, video traffic can be handled transparently as generic application-level traffic.  However, as the volume of video traffic continues to grow, it's becoming increasingly important to further.  In this case, the immersive content is typically referred to as volumetric media.  One way to represent the volumetric media is to use point clouds, where streaming a single object may easily <del> require a bitrate of 30 Mbps or higher.  Refer to PCC for more details. </del>  2.2. 3.1. Adaptive BitRate (ABR) is a sort of application-level response <del> strategy in which the receiving media player attempts to detect the available bandwidth of the network path by experiment or by observing the successful application-layer download speed, then chooses a video bitrate (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 in the player (such as available memory, CPU, display size, etc.). </del>  The choice of bitrate occurs within the context of optimizing for <del> some metric monitored by the video player, such as highest achievable video quality, or lowest rate of expected rebuffering events. </del>  3.2. <del> ABR playback is commonly implemented by video players using HLS </del>  RFC8216 or DASH DASH to perform a reliable segmented delivery of <del> video data over HTTP.  Different player implementations and receiving devices use different strategies, often proprietary algorithms (called rate adaptation or bitrate selection algorithms), to perform available bandwidth estimation/prediction and the bitrate selection. Most players only use passive observations, i.e., they do not generate probe traffic to measure the available bandwidth. </del>  This kind of bandwidth-measurement systems can experience trouble in several ways that can be affected by networking design choices. 4. <del> This document requires no actions from IANA. </del>  5.  This document introduces no new security issues.

NAME - is this roughly what you were expecting to see, on Issue 22? Please advise :-)
I'm having a conversation with NAME about URL, but the short summary here is that I need to tighten up some of the language about what we are saying about strangely HTTPish UDP traffic, from an observer's perspective, and to do so without starting to say things that either duplicate (bad) or contradict (worse) the QUIC manageability draft on this point. You'll note that the QUIC issue is still under discussion, so probably need to revisit this after they close their Issue. Fortunately, I bet NAME will make sure I behave ... and I appreciate that.
Is it worth also saying about the expectations networks allows streaming traffic over TCP and QUIC to flow freely? I think this could just be a short paragraph that highlights that when other variables are isolated, fairness/contention between TCP and QUIC is most likely a function of the congestion controllers at play.
I THINK the current text in this draft (as of 10 May) is consistent with the QUIC manageability draft, but it will be GREAT for us to do a final check after QUIC finishes working on their draft.
NAME - thank you for this suggestion. See what you think of the current text.
And, like magic, this just popped up on the QUIC mailing list 15 minutes ago. I swear, I could write this script! "The SNI extraction and Appendix A sections of manageability provide guidance that won't work with Chrome. I opened issues 357 and 358 about this. They should be easy to resolve. I apologize for the late notice (I haven't been keeping track of these documents closely) but I do think these do need to be addressed before publication."
The text LGTM. I'll leave it to you editors to decide and battle out where/if to land it.
NAME I'm going to do a commit that moves this text to an actual reasonable place in the draft (I'll be looking at your suggestion to put it near ABR, and I'll try to Do The Right Thing). Probably best not to merge this PR until I commit that, OK?
NAME and NAME I think this PR is ready to merge. Do either of you agree?
Since the intro says relate to quality of experience in internet video delivery. I'm a little surprised to not see anything about the effects on video QoE caused by contention in the network, or the role that fairness between other flows and/or protocols plays on video and other applications. Finally, its been interesting to see how large content providers have reduced streaming bitrates in response to large-scale contention during the COVID pandemic, whether voluntarily or via external pressures. This is especially curious when content is distributed via ABR technologies which should accommodate switching to lower bitrates. (I've heard anecdotal reasoning that the detection of contention is too slow, but unsure if that is really true).
One of the more logical explanations of the situation I have I read: URL EU asking Netflix to drop the bitrates was a total BS IMO.
It is worth noting that some protocols rely on the transport layer bwe/cc (the ones that are TCP based) while others have to implement their own mechanisms (udp based like QUIC or RTP). In that regard, I would differentiate the loss based bwe/cc algorithms (TCP, new Reno, bbr) vs the delay based ones (copa).
I'm planning to focus a PR for this issue on fairness and contention, but defer to the "Extremely Unpredictable Usage Profiles" section, which we've recently merged into Master, for anything about CoViD-19-related impacts on network performance for streaming media. Please let me know if that's not a good plan.
OK, I'm about 10 commits (it seemed like more) into the PR for this issue, and am now thinking that I should divide what is now the "Evolution of Transport Protocols and Transport Protocol Behaviors" section into a UDP/TCP section that comes before the ABR section, because those are the protocols that people use with ABR today, and a QUIC section (that is actually "evolution") that remains after the ABR section. NAME and NAME do you have any thoughts about that? I'm pretty sure it would allow us to tighten up the discussion of interaction between ABR and transport protocol behavior in the ABR section.
Sounds reasonable to me, I think.
I'll make that split (and see if I can do that without conflicts - I think I'm only moving text in , so should be easy.
The content here is pretty good, but I think maybe goes a little out of scope for what I thought this doc should do. I'd be in favor of more depth on the effects of congestion on video QoE. I'm agnostic on whether to drop some of the depth here on congestion control in general (it's good stuff, but reading it I feel like this is for an iccrg informational topic instead of a mops one.) Also the section location seems to be the first one after the intro. Should this move into the ABR section, maybe with a note about congestion response being the primary driver for ABR bitrate selection?

Abstract This document provides an overview of operational networking issues  <ins> that pertain to quality of experience in streaming of video and other </ins> high-bitrate media over the internet. 1. compound annual growth rate continuing at 34% (from Appendix D of CVNI). <ins> A substantial part of this growth is due to increased use of streaming video, although the amount of video traffic in real-time communications (for example, online videoconferencing) has also grown significantly.  While both streaming video and videoconferencing have real-time delivery and latency requirements, these requirements vary from one application to another.  For example, videoconferencing demands an end-to-end (one-way) latency of a few hundreds of milliseconds whereas live streaming can tolerate latencies of several seconds. This document specifically focuses on the streaming applications and defines streaming as follows: Streaming is transmission of a continuous media from a server to a client and its simultaneous consumption by the client.  Here, continous media refers to media and associated streams such as video, audio, metadata, etc.  In this definition, the critical term is "simultaneous", as it is not considered streaming if one downloads a video file and plays it after the download is completed, which would be called download-and-play. This has two implications.  First, server's transmission rate must (loosely or tightly) match to client's consumption rate for an uninterrupted playback.  That is, the client must not run out of data (buffer underrun) or take more than it can keep (buffer overrun) as any excess media is simply discarded.  Second, client's consumption rate is limited by not only bandwidth availability but also the real- time constraints.  That is, the client cannot fetch media that is not available yet. </ins> In many contexts, video traffic can be handled transparently as generic application-level traffic.  However, as the volume of video traffic continues to grow, it's becoming increasingly important to further.  In this case, the immersive content is typically referred to as volumetric media.  One way to represent the volumetric media is to use point clouds, where streaming a single object may easily  <ins> require a bitrate of 30 Mbps or higher.  Refer to MPEGI and PCC for more details. </ins> 2.2. 3.1. Adaptive BitRate (ABR) is a sort of application-level response  <ins> 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.). </ins> The choice of bitrate occurs within the context of optimizing for  <ins> some metric monitored by the client, such as highest achievable video quality or lowest chances for a rebuffering (playback stall). </ins> 3.2.  <ins> ABR playback is commonly implemented by streaming clients using HLS </ins> RFC8216 or DASH DASH to perform a reliable segmented delivery of  <ins> media over HTTP.  Different implementations use different strategies ABRSurvey, often proprietary algorithms (called rate adaptation or bitrate selection algorithms) to perform available bandwidth estimation/prediction and the bitrate selection.  Most clients only use passive observations, i.e., they do not generate probe traffic to measure the available bandwidth. </ins> This kind of bandwidth-measurement systems can experience trouble in several ways that can be affected by networking design choices. 4.  <ins> **Note to Reviewers^^ - this section includes some material that may be tutorial for some readers.  We can decide how to say that, if the tutorial material is worth keeping.  Spencer thought it was worth including, because it provides a contrast to the material on QUIC, which is significantly less tutorial, unless you participated in the QUIC working group. 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. 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. 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. 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. 4.1. 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). 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. 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. 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. 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. 4.2. 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. 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. 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. 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. 4.3. 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. 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. 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. 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. As noted in tcp-behavior, there is increasing interest in transport protocol behaviors that responds 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 I-D.ietf-quic-recovery defines a basic algorithm with transport behavior that is roughly similar to TCP NewReno RFC6582. However, QUIC senders can and do unilaterally chose to use different algorithms such as loss-based CUBIC RFC8312, delay-based COPA or BBR, or even something completely different 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. 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. 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. 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. </ins> 5. <ins> "Encrypted Media" has at least three meanings: Media encrypted at the application layer, typically using some sort of Digital Rights Management (DRM) system, and typically retaining this encryption "at rest", when it is stored at senders and receivers, Media encrypted by the sender at the transport layer, and remaining encrypted until it reaches the ultimate media consumer (in this document, referred to as "end-to-end media encryption"), and 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 descryption 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") Both "hop-by-hop" and "end-to-end" encrypted transport may carry media that is, in addition, encrypted at the application layer. Each of these encryption strategies is intended to achieve a different goal.  For instance, application-level encryption may be used for business purposes, such as avoiding piracy or enforcing geographic restrictions on playback, while transport-layer encryption may be used to prevent media steam manipulation or to protect manifests.  This document does not take a position on whether those goals are "valid" (whatever that might mean). In this document, we will focus on media encrypted at the transport layer, whether encrypted "hop-by-hop" or "end-to-end". Both "End-to-End" and "Hop-by-Hop" media encryption have implications for streaming operators. 5.1. 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. codaspy 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 breaks privacy as certainly as examining decrypted traffic. 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. 5.2. Although the IETF has put considerable emphasis on end-to-end streaming media encryption, there are still important use cases that require the insertion of intermediaries. There are a variety of ways to involve intermediaries, and some are much more intrusive than others. From a content provider's perspective, a number of considerations are in play.  The first question is likely whether the content provider intends that intermediaries are explicitly addressed from endpoints, or whether the content provider is willing to allow intermediaries to "intercept" streaming content transparently, with no awareness or permission from either endpoint. If a content 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. Assuming that a content provider does intend to allow intermediaries to participate in content streaming, and does intend to provide some level of privacy for endpoints, there are a number of possible tools, either already available or still being specified.  These include Server And Network assisted DASH 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. "Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP)" RFC8723 - this specification provides a cryptographic transform for the Secure Real-time Transport Protocol that provides both hop-by-hop and end-to-end security guarantees. 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. If a content provider chooses not to involve intermediaries, this choice should be carefully considered.  As an example, if media manifests are encrypted end-to-end, network providers who had been able to lower offered quality and reduce on their networks will no longer be able to do that.  Some resources that might inform this consideration are in RFC8825 (for WebRTC) and I-D.ietf-quic- manageability (for HTTP/3 and QUIC). 5.3. "End-to-end" media encryption offers the potential of providing privacy for streaming media consumers, with the idea being that if an unauthorized intermediary can't decrypt streaming media, the intermediary can't use Deep Packet Inspection (DPI) to examine HTTP request and response headers and identify the media content being streamed. "End-to-end" media encryption became much more widespread in the years since RFC7258 was issued, which identified pervasive monitoring as a much greater threat than previously appreciated.  After the Snowden disclosures, many content providers made the decision to use HTTPS protection - HTTP over TLS - for most or all content being delivered as a routine practice, rather than in exceptional cases for content that was considered "sensitive". 6. This document requires no actions from IANA. 7. </ins> This document introduces no new security issues. <ins> 8. Thanks to Mark Nottingham, Glenn Deen, Dave Oran, Aaron Falk, Kyle Rose, Leslie Daigle, Lucas Pardue, Matt Stock, Alexandre Gouaillard, and Mike English for their very helpful reviews and comments. </ins>


4.3.1. <del> When the bitrate selection is successfully chosen below the available capacity of the network path, the response to a segment request will typically complete in less absolute time than the duration of the requested segment.  The resulting idle time within the connection carrying the segments has a few surprising consequences: Mobile flow-bandwidth spectrum and timing mapping. 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. 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. </del>  4.3.2.

I'm looking at "{{RFC7661}} provides some mitigations for this effect at the TCP transport layer, for senders who anticipate a high incidence of this problem", and noticing that RFC 7661 is Experimental. Our draft is targeting Informational, so downrefs aren't a problem, but do we have fair confidence that people have implemented this? Maybe the right thing to do in an OPS draft is to say that understanding what the TCP implementations you're using support, in mitigating this effect, and realizing that the answers might be "RFC 7661", "something else", "both", or "nothing".
I have seen servers deliberately disabling SSR flag so TCP does not restart after an idle period.
We could add these examples: $> sysctl net.ipv4.tcpslowstartafteridle $> sysctl -w net.ipv4.tcpslowstartafteridle=0 And we'll split out the mitigations ...
This is a more formal reference: URL
It says: 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. Well, TCP slow-start restart happens when TCP stays idle long enough. "Long enough" is a factor for RTT, so I don'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 linux'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.
Linked to (which is already addressed adequately IMO, so we can close this issue).
Fixed in .
Fixed the reference.

4.3.1.  <ins> When the bitrate selection is chosen substantially below the available capacity of the network path, the response to a segment request will typically complete in much less absolute time than the duration of the requested segment, leaving significant idle time between segment downloads.  This can have a few surprising consequences: TCP slow-start when restarting after idle requires multiple RTTs to re-establish a throughput at the network's available capacity. When the active transmission time for segments is substantially shorter than the time between segments leaving an idle gap between segments that triggers a restart of TCP slow-start, the estimate of the successful download speed coming from the application- visible receive rate on the socket can thus end up much lower than the actual available network capacity, preventing a shift to the most appropriate bitrate.  RFC7661 provides some mitigations for this effect at the TCP transport layer, for senders who anticipate a high incidence of this problem. Mobile flow-bandwidth spectrum and timing mapping can be impacted by idle time in some networks.  The carrier capacity assigned to a link can vary with activity.  Depending on the idle time characteristics, this can result in a lower available bitrate than would be achievable with a steadier transmission in the same network. Some receive-side ABR algorithms such as ELASTIC are designed to try to avoid this effect.  Another way to mitigate this effect is by the help of two simultaneous TCP connections is explained in MMSys11 for Microsoft Smooth Streaming.  In some cases, the system-level TCP slow-start restart can be disabled oreilly-tcpblocks. </ins> 4.3.2.