Change:
4.4. <ins> A variety of business models exist for producers of streaming media. Some content providers derive the majority of the revenue associated with streaming media directly from consumer subscriptions or one-time purchases.  Others derive the majority of their streaming media associated revenue from advertising.  Many content providers derive income from a mix of these and other sources of funding.  The inclusion of advertising alongside or interspersed with streaming media content is therefore common in today's media landscape. Some commonly used forms of advertising can introduce potential user experience issues for a media stream.  This section provides a very brief overview of a complex and evolving space, but a complete coverage of the potential issues is out of scope for this document. The same techniques used to allow a media player to switch between renditions of different bitrates at segment or chunk boundaries can also be used to enable the dynamic insertion of advertisements. Ads may be inserted either with Client Side Ad Insertion (CSAI) or Server Side Ad Insertion (SSAI).  In CSAI, the ABR manifest will generally include links to an external ad server for some segments of the media stream, while in SSAI the server will remain the same during advertisements, but will include media segments that contain the advertising.  In SSAI, the media segments may or may not be sourced from an external ad server like with CSAI. In general, the more targeted the ad request is, the more requests the ad service needs to be able to handle concurrently.  If connectivity is poor to the ad service, this can cause rebuffering even if the underlying video assets (both content and ads) are able to be accessed quickly.  The less targeted, the more likely the ad requests can be consolidated and can leverage the same caching techniques as the video content. In some cases, especially with SSAI, advertising space in a stream is reserved for a specific advertiser and can be integrated with the video so that the segments share the same encoding properties such as bitrate, dynamic range, and resolution.  However, in many cases ad servers integrate with a Supply Side Platform (SSP) that offers advertising space in real-time auctions via an Ad Exchange, with bids for the advertising space coming from Demand Side Platforms (DSPs) that collect money from advertisers for delivering the advertisements.  Most such Ad Exchanges use application-level protocol specifications published by the Interactive Advertising Bureau IAB-ADS, an industry trade organization. This ecosystem balances several competing objectives, and integrating with it naively can produce surprising user experience results.  For example, ad server provisioning and/or the bitrate of the ad segments might be different from that of the main video, either of which can sometimes result in video stalls.  For another example, since the inserted ads are often produced independently they might have a different base volume level than the main video, which can make for a jarring user experience. Additionally, this market historically has had incidents of ad fraud (misreporting of ad delivery to end users for financial gain).  As a mitigation for concerns driven by those incidents, some SSPs have required the use of players with features like reporting of ad delivery, or providing information that can be used for user tracking.  Some of these and other measures have raised privacy concerns for end users. In general this is a rapidly developing space with many considerations, and media streaming operators engaged in advertising may need to research these and other concerns to find solutions that meet their user experience, user privacy, and financial goals.  For further reading on mitigations, BAP has published some standards and best practices based on user experience research. 4.5. </ins> This kind of bandwidth-measurement system can experience trouble in several ways that are affected by networking issues.  Because adaptive application-level response strategies are often using rates

Discussion:
Sorry for the delay on this! Here's a rebased copy of URL we can work from if there's still in adding this section.
NAME my apologies on this - I told NAME and NAME I'd work on this, just before coming down with the plague. Thank you for rebasing the proposal, and yes, we are still interested in adding this section (speaking for the editors, not for the working group). We're in the I-D submission blackout zone now, so let's continue discussion, and we can submit something after IETF 111 opens back up.
I had a few comments in the prior pr, but I'm not sure I quite got across what I meant. I drafted an alternative proposal as a quick straw man example of what I meant, maybe we could do some merger that includes some content along these lines? I was also thinking to put it in the ABR section instead of the bandwidth section, probably. Not sure if this goes too far?
NAME now that we're using Github Actions, it looks like "First-time contributors need a maintainer to approve running workflows", and we actually caught problems when using CircleCI, so we probably want to do that, don't we? If so - who are the maintainers who should be approving this? I'm guessing that this has something to do with URL, but of course, I'm not sure ...
NAME the current slide deck for next week's MOPS session has the issue associated with this PR as our last blocking issue before WGLC, so if we (you, me, NAME NAME can close on this before the meeting, we can update the slide deck and tell the WG that we're just cleaning up for a couple of weeks after IETF 111, and then going forward. Does that make sense to you?
NAME That makes sense to me! I will, unfortunately, not be able to attend IETF 111 due to a previously scheduled commitment, but I will attempt to integrate NAME feedback here beforehand so you can bring that message to the WG session.
Sorry for the late push! We've had even less Internet connectivity than I had expected. Let me know what you think of this synthesis, and whether a section on segmentation and keyframes is worth including. Thanks!

NAME I agree that this probably needs another editorial pass to deduplicate some of the merged text and tighten up the style, but I've tried to clean up all the other loose ends so you can merge this if/when you're ready. Let me know if you need me to make any additional changes in this PR. Thanks!
Thanks Mike, this is fantastic. Much obliged. We'll discuss in the next editor's session, and likely at least one of us will make an editorial pass before long, I expect. (NAME I believe you're still the owner--want to take a final pass? I think another set of eyes would be invaluable here, and your judgement on these matters is impeccable, IMHO...)
NAME has questionable judgement about "impeccable taste", but I should be able to do that ...
Since we're going to be doing a final editorial pass anyway, I'm merging this PR and closing the issue now. I don't see us making significant changes to the current proposed text - as Jake says, it looks quite good. Thanks, NAME for your work on this!
Originally proposed by Matt Stock here: URL
We THINK this is different from general DNS performance impacts, when you do client side ad insertion for URLs that the media provider is handing you based on the specific customer who is looking at the media. The actual problem is probably media player-specific, but but we can probably say something useful in a sentence or two.
BTW: comments are welcomed on whether or not we should acknowledge the existence of DNS-based ad-blockers and their relevance to this issue in this document.
So, now that I've slept on this (sort of), I was leaning toward adding at least a sentence or two about DNS-based ad-blockers, because that was a topic I THOUGHT I understood, but apparently not in much depth. ISTM that the question I SHOULD have asked, is "that's a fascinating question. Is there anything that a media provider can do differently, if we describe the issue?" ISTM that if what we say would be actionable for the designated audience, it makes sense to say it in the draft.

If a player implementer is aware of the potential for trouble from a change in hostname for a stream, they could run that request a little early as a mitigation to give time for the DNS to settle out, or to do any kind of pre-request to an upcoming non-recently-used hostname or something. Also the operator could chose to run server-side ads instead. (That might not be an exhaustive list, but it's at least a couple examples.) Maybe also worth mentioning it can be more of an issue if you're running a tight latency budget. But yeah, I think it's at least somewhat actionable for operators if the issue is on their radar.
Conclusion way back when was that we'd add text if we got to it with a deadline that we missed long ago. So this is won'tfix.
Describe in general terms segments and frame types, tradeoffs associated with segment size and keyframe interval selection. (related to idle-time and caching) Thanks NAME for the suggestion as part of URL
This is about low-latency and where you can start rendering in a media stream. Mention and explain briefly? This isn't quite about the NETWORK, but it's about caching, which is probably in the network. Keyframes can also be used for thumbnails when you hover over something. More keyframes gives you more flexibility in where you can start rendering, but is also larger and comes with a bandwidth and path occupancy cost.
Insert this material in "For further reading" (}?
This is now addressed in the reading list section. Issue can be closed.
My thought here was that stream characteristics like GOP sizing place a constraint on switching opportunities for renditions (ABR) and ad insertion, which can have an impact on bandwidth utilization, etc. I thought some explanatory text might help pull those sections together a bit more, but I'm fine with it just being covered in the further reading, too.
It is not very easy to correctly discuss the trade-offs between the key frame internal, segment size, encoding quality, impact on the storage, request rate and all that. There are detailed studies that do an excellent job on explaining these trade-offs, so referring the readers to these studies is better IMO.
Closing this issue as the further reading section identifies the relevant studies.

Advertising is an important part of the video delivery landscape and has an impact on network design and operational considerations in streaming video, for sure. NAME gave a pull request that's a decent start here: URL There are some unanswered comments in that pull request, but we should consider adding such a section and refining it even in the absence of responses.
Ads are evil :) Could the IETF ban them?
NAME will review proposed text in PR