Change:
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, <del> and when to send it.  So, the way some UDP-based applications interact with other users has changed. It is also worth pointing out that because UDP has no transport-layer </del> <ins> and when to send it.  Because UDP itself has no transport-layer </ins> feedback mechanisms, UDP-based applications that send and receive substantial amounts of information are expected to provide their own <del> feedback mechanisms.  This expectation is most recently codified in Best Current Practice RFC8085. </del> <ins> feedback mechanisms, and to respond to the feedback the application receives.  This expectation is most recently codified in Best Current Practice RFC8085. In contrast to adaptive segmented delivery over a reliable tansport as described in adapt-deliver, some applications deliver streaming media using an unreliable transport, and rely on a variety of approaches, including: 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, RTP RFC3550, which can notice loss and repair some limited reordering, SCTP RFC4960, which can use partial reliability RFC3758 to recover from some loss, but can abandon recovery to limit head-of-line blocking, and 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. 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. Congestion avoidance strategies for deployments using unreliable transport protocols vary widely in practice, ranging from being entirely unresponsive to congestion, to using feedback signaling to change encoder settings (as in RFC5762), to using fewer enhancement layers (as in RFC6190), to using proprietary methods to detect "quality of experience" issues and turn off video in order to allow less bandwidth-intensive media such as audio to be delivered. </ins> RTP relies on RTCP Sender and Receiver Reports RFC3550 as its own feedback mechanism, and even includes Circuit Breakers for Unicast

Discussion:
I've edited NAME suggested text a bit, but the proposed structure was WAY more coherent than what I had assembled. Thank you for that!
From NAME 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, NAME I'm actually pretty sure Section 5.7 doesn'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.