Original text:
constraints using two independent feedback loops: Media servers often respond to application-level feedback from the <del> 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. </del>  <del> Media servers also typically implement transport protocols with </del>  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. other, and this can result in QOE for users that is significantly lower than what could have been achieved.  In one example, if a media server overestimates the available bandwidth to the media player, sending at a higher rate. In order to avoid these types of situations, which can potentially <del> 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. </del>  3.2.1. Mobile flow-bandwidth spectrum and timing mapping can be impacted by idle time in some networks.  The carrier capacity assigned to a <del> link can vary with activity.  Depending on the idle time characteristics, this can result in a lower available bitrate than would be achievable with a steadier transmission in the same network. </del>  Some receiver-side ABR algorithms such as ELASTIC are designed to try to avoid this effect. https://github.com/ietf-wg-mops/draft-ietf-mops-streaming- opcons/blob/main/living-doc-mops-streaming-opcons.md [4] <del> Editor's note: The link above might or might not be changed during </del>  IESG Evaluation.  See https://github.com/ietf-wg-mops/draft-ietf- mops-streaming-opcons/issues/114 [5] for updates. 11. Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran, <del> Eric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham, Matt Stock, Mike English, Renan Krishna, Roni Even, Sanjay Mishra, and Will Law for very helpful suggestions, reviews and comments. </del>  12.  References

Reviewer comments:
Also add Linda to ACKs and add stream: IETF (this is now an XML2RFCv3 thing)
From NAME
responding to the application-level feedback that indicates a bottleneck link somewhere along the path. We agree that "link" is ambiguous. In this section, we're talking about a bottleneck, so we don't need to to say "link", BUT we will clean up other occurrences of "link" in the document - one is actually a URL. implementing some forms of congestion control that probe for bandwidth. The conclusion says that the QoE is poorer when the two methods don't coordinate. Question 2: Both methods are implemented on the Media server, they should coordinate by nature, aren't they? You might think so, but they don't, for various reasons (transport protocols being implemented by OS vendors, and media servers and players are implemented by completely different people. We say that in 3.2, but we describe media servers as "implementing transport protocols". That should have been "rely on". This might change, with transport protocols being implemented in user space and packaged as libraries that are shipped media servers, but that's the case today.

Revised text:
constraints using two independent feedback loops: Media servers often respond to application-level feedback from the  <ins> media player that indicates a bottleneck 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. </ins>  <ins> Media servers also typically rely on transport protocols with </ins> 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. other, and this can result in QOE for users that is significantly lower than what could have been achieved. <ins> One might wonder why media servers and transport protocols are each blissfully ignorant of what the other is doing, and there are multiple reasons for that, but one reason is that media servers may be implemented to run under a general-purpose operating system which typically has its transport protocols implemented in the operating system kernel, making decisions that the media server never knows about. </ins> In one example, if a media server overestimates the available bandwidth to the media player, sending at a higher rate. In order to avoid these types of situations, which can potentially  <ins> affect all the users whose streaming media traverses a bottleneck, there are several possible mitigations that streaming operators can use, but the first step toward mitigating a problem is knowing when that problem occurs. </ins> 3.2.1. Mobile flow-bandwidth spectrum and timing mapping can be impacted by idle time in some networks.  The carrier capacity assigned to a  <ins> physical or virtual link can vary with activity.  Depending on the idle time characteristics, this can result in a lower available bitrate than would be achievable with a steadier transmission in the same network. </ins> Some receiver-side ABR algorithms such as ELASTIC are designed to try to avoid this effect. https://github.com/ietf-wg-mops/draft-ietf-mops-streaming- opcons/blob/main/living-doc-mops-streaming-opcons.md [4]  <ins> Editor's note: The URL above might or might not be changed during </ins> IESG Evaluation.  See https://github.com/ietf-wg-mops/draft-ietf- mops-streaming-opcons/issues/114 [5] for updates. 11. Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran,  <ins> Eric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Linda Dunbar, Lucas Pardue, Mark Nottingham, Matt Stock, Mike English, Renan Krishna, Roni Even, Sanjay Mishra, and Will Law for very helpful suggestions, reviews and comments. </ins> 12.  References