Draft: draft-ietf-mops-streaming-opcons

Commentary: 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 . 
 had what I think is an excellent suggestion of one line per sentence : 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 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 wo n't have conflicts . Should be pretty quick , right ? 
 ( * note , there is another pull request also that would be affected if we do it now : ) 
 Closing , do n'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 (      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 . ( This probably goes in the caching section as that 's written . ) 
 + Glenn 's comment : also capture latency constraints as a usability / qos part for  vs. pre - recorded and expected - popular . 
 I would like to think that PR 30 is a start here ... 
 was merged , but this issue was n't closed . Closing now ...
Paragraph (version A):
TBD: pros, cons, tradeoffs of caching designs at different locations
within the network?
Paragraph (version A):
Peak vs. average provisioning, and effects on peering point
congestion under peak load?
Paragraph (version A):
Provisioning issues for caching systems?
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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).
Paragraph (version A):
The causes of unpredictable usage described in sec-unpredictable were
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.
Paragraph (version B):
The causes of unpredictable usage described in sec-unpredict were
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.