Draft: draft-ietf-mops-streaming-opcons

Commentary: This definitely needs more work ! 
 and - I have three notes in the section I 've . I 'll hit this again later in the week , but if you can express opinions about any of them , that would be very helpful . 
 In the call we discussed this and we feel like we do n'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 suggestions - let me spend a couple of hours on this , and then you two can either merge it or reject it . 
 and see what you think . I 'm also ok with closing as wontfix , but wanted to give it a try . 
 and any thoughts on this PR ? I tried to reflect  '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 (   ) 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 . 
 For many , poor  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 .
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
In one example, if a media server overestimates the available
handwidth to the media player,
Paragraph (version B):
the transport protocol detects loss due to congestion, and reduces
its sending window size per round trip,
Paragraph (version B):
the media server adapts to application-level feedback from the
media player, and reduces its own sending rate,
Paragraph (version B):
the transport protocol can't probe for available path bandwidth by
sending at a higher rate.
Paragraph (version B):
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.
Paragraph (version B):
There are many reasons why path characteristics might change
suddenly, for example,
Paragraph (version B):
"cross traffic" that traverses part of the path, especially if
this traffic is "inelastic", and does not, itself, respond to
indications of path congestion.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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).
Paragraph (version A):
acknowledgments for packets that were successfully sent and received,
and packet timeouts for packets that were not.
Paragraph (version B):
acknowledgements for packets that were successfully sent and
received, and packet timeouts for packets that were not.