Change:
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.

Discussion:
HTTP can make use of already-deployed caching infrastructure. Unreliable media delivery using RTP and other UDP-based protocols is <del> 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. </del> <ins> 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. </ins> 3.

standardized media-relevant information to the CDNs while they are fetching data.  CTA-5004 was developed exactly for this purpose. <del> 5.7. 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. 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. 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. 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. More details about congestion avoidance strategies used with unreliable transport protocols are included in udp-behavior. </del> 6. Because networking resources are shared between users, a good place

DNS requests, in practice, that was rare enough that DNS included few mechanisms to resolve contention between DNS users and other users (whether they are also using DNS, or using other application <del> protocols). </del> <ins> protocols that share the same pathways). </ins> In recent times, the usage of UDP-based applications that were not simple query-response protocols has grown substantially, and since

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