Draft: draft-ietf-mops-streaming-opcons

Commentary: Sorry for the delay on this ! Here 's a rebased copy of we can work from if there 's still in adding this section . 
 my apologies on this - I told and 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 ? 
 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 , do n't we ? If so - who are the maintainers who should be approving this ? I 'm guessing that this has something to do with , but of course , I 'm not sure ... 
 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 , 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 ? 
 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 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 ! 
 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  , 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 . ( 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 ... ) 
 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 do n't see us making significant changes to the current proposed text - as  says , it looks quite good . Thanks , for your work on this ! 
 Originally proposed by   here : 
 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 for the suggestion as part of 
 This is about low - latency and where you can start rendering in a media stream . Mention and explain briefly ? This is n'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 . 
  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 . gave a pull request that 's a decent start here : 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 ? 
 will review proposed text in PR
Paragraph (version B):
A simple model of video playback can be described as a video stream
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
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 ad workflows are
introduced.
Paragraph (version B):
The challenges in filling the buffer in a timely way fall into two
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.