Original text:
2.2.  The bitrate requirements in scaling are per end-user actively consuming a media feed, so in the worst case, the bitrate demands can be multiplied by the number of simultaneous users to find the bandwidth requirements at peering or ingest points can be reduced to as low as a per-feed requirement instead of a per-user requirement. <del> 2.3. </del>  When demand for content is relatively predictable, and especially when that content is relatively static, caching content close to at the same spot in the video for all players playing the segment delivered from that cache node. <del> 2.4. </del>  Historical data shows that users consume more video and videos at higher bitrates than they did in the past on their connected devices. jump over the years due to increased consumption of entertainment as well as conversational video. <del> 2.5. </del>  Although TCP/IP has been used with a number of widely used applications that have symmetric bandwidth requirements (similar watch for increasing numbers of end users uploading significant amounts of content. <del> 2.6. </del>  The causes of unpredictable usage described in sec-unpredict were more or less the result of human choices, but we were reminded during 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 <del> acknowledgments for packets that were successfully sent and received, and packet timeouts for packets that were not. </del>  The success of the largely TCP-based Internet is evidence that the mechanisms TCP used to achieve equilibrium quickly, at a point where

Reviewer comments:
This definitely needs more work!
NAME and NAME - I have three notes in the section I've added. I'll hit this again later in the week, but if you can express opinions about any of them, that would be very helpful.
NAME In the call we discussed this and we feel like we don't need to say anything about this in addition to what we already said in Section titled "Bitrate Detection Challenges". So, maybe we can drop and close this?
I actually like NAME suggestions - let me spend a couple of hours on this, and then you two can either merge it or reject it.
NAME and NAME see what you think. I'm also ok with closing as wontfix, but wanted to give it a try.
NAME and NAME any thoughts on this PR? I tried to reflect Jake's high-level comments, which were even more helpful and actionable than usual ...
This reads much better than the initial version, thanks.
Pulling the TBD out of the draft text and capturing it here instead. Suggestion from mic at IETF 106 (Mark Nottingham) in response to call for help on capturing the mismatch between supply and demand of bandwidth with regard to video: Dive into the different constraints coming from different parts of the network or distribution channels. (regarding questions about how to describe the disconnect between demand vs. capacity, while keeping good archival value.) "These are big numbers, but the internet has grown over time, and CDN capacities have grown over time. Is it last mile? Probably not--Is it middle mile? Maybe that's more interesting. It it CPU? Is it network cards? Is it the economics of your peering relationships? Unpicking those bits might help a bit. URL
For many, poor Wifi is the culprit. For many others, the ISP aggregation links are the culprit during the prime times (since most such links are oversubscribed/oversold). For some, the CDN issues create problems and for rare cases, the origin drowns and everybody gets upset. For certain environments like student dorms, campus networks, libraries, airport cafes, it is just lack of bandwidth for the power users.
Thanks, this version reads much better to me. I have no objections.

Revised text:
2.2. <ins> Even when the bandwidth requirements for video streams along a path are well understood, additional analysis is required to understand the contraints on bandwidth at various points in the network.  This analysis is necessary because media servers may react to bandwith constraints using two independent feedback loops: Media servers often respond to application-level feedback from the media player that indicates a bottleneck link somewhere along the path, by adjusting the amount of media that the media server will send to the media player in a given timeframe.  This is described in greater detail in sec-abr. Media servers also typically implement transport protocols with capacity-seeking congestion controllers that probe for bandwidth, and adjust the sending rate based on transport mechanisms.  This is described in greater detail in sec-trans. The result is that these two (potentially competing) "helpful" mechanisms each respond to the same bottleneck with no coordination between themselves, so that each is unaware of actions taken by the other, and this can result in a quality of experience for users that is significantly lower than what could have been achieved. In one example, if a media server overestimates the available handwidth to the media player, the transport protocol detects loss due to congestion, and reduces its sending window size per round trip, the media server adapts to application-level feedback from the media player, and reduces its own sending rate, the transport protocol sends media at the new, lower rate, and confirms that this new, lower rate is "safe", because no transport-level loss is occuring, but because the media server continues to send at the new, lower rate, the transport protocol's maximum sending rate is now limited by the amount of information the media server queues for transmission, so the transport protocol can't probe for available path bandwidth by sending at a higher rate. In order to avoid these types of situations, which can potentially affect all the users whose streaming media traverses a bottleneck link, there are several possible mitigations that streaming operators can use, but the first step toward mitigating a problem is knowing when that problem occurs. 2.2.1. There are many reasons why path characteristics might change suddenly, for example, "cross traffic" that traverses part of the path, especially if this traffic is "inelastic", and does not, itself, respond to indications of path congestion. routing changes, which can happen in normal operation, especially if the new path now includes path segments that are more heavily loaded, offer lower total bandwidth, or simply cover more distance. Recognizing that a path carrying streaming media is "not behaving the way it normally does" is fundamental.  Analytics that aid in that recognition can be more or less sophisticated, and can be as simple as noticing that the apparent round trip times for media traffic carried over TCP transport on some paths are suddenly and significantly longer than usual.  Passive monitors can detect changes in the elapsed time between the acknowledgements for specific TCP segments from a TCP receiver, since TCP octet sequence numbers and acknowledgements for those sequence numbers are "carried in the clear", even if the TCP payload itself is encrypted.  See tcp- behavior for more information. As transport protocols evolve to encrypt their transport header fields, one side effect of increasing encryption is that the kind of passive monitoring, or even "performance enhancement" (RFC3135) that was possible with the older transport protocols (UDP, described in udp-behavior and TCP, described in tcp-behavior) is no longer possible with newer transport protocols such as QUIC (described in quic-behavior).  The IETF has specified a "latency spin bit" mechanism in Section 17.4 of RFC9000 to allow passive latency monitoring from observation points on the network path throughout the duration of a connection, but currently chartered work in the IETF is focusing on end-point monitoring and reporting, rather than on passive monitoring. One example is the "qlog" mechanism I-D.ietf-quic-qlog-main-schema, a protocol-agnostic mechanism used to provide better visibility for encrypted protocols such as QUIC (I-D.ietf-quic-qlog-quic-events) and for HTTP/3 (I-D.ietf-quic-qlog-h3-events). 2.3. </ins> The bitrate requirements in scaling are per end-user actively consuming a media feed, so in the worst case, the bitrate demands can be multiplied by the number of simultaneous users to find the bandwidth requirements at peering or ingest points can be reduced to as low as a per-feed requirement instead of a per-user requirement.  <ins> 2.4. </ins> When demand for content is relatively predictable, and especially when that content is relatively static, caching content close to at the same spot in the video for all players playing the segment delivered from that cache node.  <ins> 2.5. </ins> Historical data shows that users consume more video and videos at higher bitrates than they did in the past on their connected devices. jump over the years due to increased consumption of entertainment as well as conversational video.  <ins> 2.6. </ins> Although TCP/IP has been used with a number of widely used applications that have symmetric bandwidth requirements (similar watch for increasing numbers of end users uploading significant amounts of content.  <ins> 2.7. </ins> The causes of unpredictable usage described in sec-unpredict were more or less the result of human choices, but we were reminded during 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  <ins> acknowledgements for packets that were successfully sent and received, and packet timeouts for packets that were not. </ins> The success of the largely TCP-based Internet is evidence that the mechanisms TCP used to achieve equilibrium quickly, at a point where