Draft: draft-ietf-mops-streaming-opcons

Commentary: Also add  to ACKs and add stream : IETF ( this is now an XML2RFCv3 thing ) 
 From 
 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 do n'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 do n't coordinate . Question 2 : Both methods are implemented on the Media server , they should coordinate by nature , are n't they ? You might think so , but they do n'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 .
Paragraph (version A):
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 A):
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):
Media servers often respond to application-level feedback from the
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.
Paragraph (version B):
Media servers also typically rely on 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):
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.
Paragraph (version A):
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):
In order to avoid these types of situations, which can potentially
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.
Paragraph (version A):
Mobile flow-bandwidth spectrum and timing mapping can be impacted
by idle time in some networks.  The carrier capacity assigned to a
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.
Paragraph (version B):
Mobile flow-bandwidth spectrum and timing mapping can be impacted
by idle time in some networks.  The carrier capacity assigned to a
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.
Paragraph (version A):
Editor's note: The link above might or might not be changed during
IESG Evaluation.  See https://github.com/ietf-wg-mops/draft-ietf-
mops-streaming-opcons/issues/114 [5] for updates.
Paragraph (version B):
Editor's note: The URL above might or might not be changed during
IESG Evaluation.  See https://github.com/ietf-wg-mops/draft-ietf-
mops-streaming-opcons/issues/114 [5] for updates.
Paragraph (version A):
Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran,
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.
Paragraph (version B):
Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran,
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.