Draft: draft-ietf-mops-streaming-opcons

Commentary: I 've edited suggested text a bit , but the proposed structure was WAY more coherent than what I had assembled . Thank you for that ! 
 From Unsure whether this section really belongs to section 5 based on its contents vs. section 5 title . Especially when placed just before section 6 , which is about transport protocols . 
 Hi , I 'm actually pretty sure Section 5.7 does n't below in Section 5 . : rofl : I moved the text from Section 5.7 INTO the section on UDP in Section 6 , with minimal editing . I need to think about whether I need to do some more editing , but at least it 's where it ought to be now .
Paragraph (version A):
Unreliable media delivery using RTP and other UDP-based protocols is
also discussed in ultralow, unreliable, udp-behavior, and hop-by-hop-
encrypt, but it is difficult to give general guidance for these
applications.  For instance, when loss occurs, the most appropriate
response may depend on the type of codec being used.
Paragraph (version B):
Unreliable media delivery using RTP and other UDP-based protocols is
also discussed in ultralow, udp-behavior, and hop-by-hop-encrypt, but
it is difficult to give general guidance for these applications.  For
instance, when loss occurs, the most appropriate response may depend
on the type of codec being used.
Paragraph (version A):
In contrast to segmented delivery, several applications use
unreliable UDP or SCTP with its "partial reliability" extension
RFC3758 to deliver Media encapsulated in RTP RFC3550 or raw MPEG
Transport Stream ("MPEG-TS")-formatted video MPEG-TS, when the media
is being delivered in situations such as broadcast and live
streaming, that better tolerate occasional packet loss without
retransmission.
Paragraph (version A):
Under congestion and loss, this approach generally experiences more
video artifacts with fewer delay or head-of-line blocking effects.
Often one of the key goals is to reduce latency, to better support
applications like videoconferencing, or for other live-action video
with interactive components, such as some sporting events.
Paragraph (version A):
The Secure Reliable Transport protocol SRT also uses UDP in an effort
to achieve lower latency for streaming media, although it adds
reliability at the application layer.
Paragraph (version A):
More details about congestion avoidance strategies used with
unreliable transport protocols are included in udp-behavior.
Paragraph (version A):
protocols).
Paragraph (version B):
protocols that share the same pathways).
Paragraph (version A):
In recent times, the usage of UDP-based applications that were not
simple query-response protocols has grown substantially, and since
UDP does not provide any feedback mechanism to senders to help limit
impacts on other users, application-level protocols such as RTP
RFC3550 have been responsible for the decisions that TCP-based
applications have delegated to TCP - what to send, how much to send,
and when to send it.  So, the way some UDP-based applications
interact with other users has changed.
Paragraph (version A):
It is also worth pointing out that because UDP has no transport-layer
feedback mechanisms, UDP-based applications that send and receive
substantial amounts of information are expected to provide their own
feedback mechanisms.  This expectation is most recently codified in
Best Current Practice RFC8085.
Paragraph (version B):
In recent times, the usage of UDP-based applications that were not
simple query-response protocols has grown substantially, and since
UDP does not provide any feedback mechanism to senders to help limit
impacts on other users, application-level protocols such as RTP
RFC3550 have been responsible for the decisions that TCP-based
applications have delegated to TCP - what to send, how much to send,
and when to send it.  Because UDP itself has no transport-layer
feedback mechanisms, UDP-based applications that send and receive
substantial amounts of information are expected to provide their own
feedback mechanisms, and to respond to the feedback the application
receives.  This expectation is most recently codified in Best Current
Practice RFC8085.
Paragraph (version B):
raw MPEG Transport Stream ("MPEG-TS")-formatted video MPEG-TS over
UDP, which makes no attempt to account for reordering or loss in
the transport,
Paragraph (version B):
RTP RFC3550, which can notice loss and repair some limited
reordering,
Paragraph (version B):
SRT SRT, which can use forward error correction and time-bound
retransmission to recover from loss within certain limits, but can
abandon recovery to limit head-of-line blocking.
Paragraph (version B):
Under congestion and loss, approaches like the above generally
experiences transient video artifacts more often and delay of
playback effects less often, as compared with reliable segment
transport.  Often one of the key goals of using a UDP-based transport
that allows some unreliability is to reduce latency and better
support applications like videoconferencing, or for other live-action
video with interactive components, such as some sporting events.