Code change:
From NAME
NAME and NAME - I agree with Magnus in his email (cut and pasted in the description), where he said "what about RMTP and SRT?", but I'm thinking that since we already have a "Why QUIC?" section, we should probably have a "Why NOT other protocols" section, rather than trying to talk about that in (what was) Section 6.1. That could also conveniently map into saying why we're not looking at "Interactive Media" in this document (and, transitively, in the BOF), and why we're not looking at "On Demand" (Media) in this document (and in the BOF). Please let me know if this is a BAD idea soon (I'm typing PRs).
NAME for media ingest, Magnus has a good point about covering not just HLS and DASH, but also making (even brief) reference to non-segmented protocols like RTMP and SRT (but really, this can be expanded to RIST, ZiXi, etc etc etc). This can just be a sentence or two; I'm happy to write it.
NAME - I had a complicated day yesterday, which became less complicated last night, so I'm not coherent enough to type text. I'll see what I can do in the next couple of hours, and if I can include these NAME suggestions.
The current definition of latency targets in the draft is based on specific numeric ranges. Those do make sense (since they ultimately come from use case requirements), but I believe we should focus more on what consequences those have for the protocol design. Reflecting on our experience with QUIC used for live video vs QUIC used for video conferencing, my proposed definition of the latency target for live video would be "latency an order of magnitude higher than one RTT". Two major examples of why this is important: When the target latency is on the order of one RTT, it makes sense to use FEC and codec-level packet loss concealment. When the target latency is in the range of many, many RTTs, selectively retransmitting only lost packets is almost always better than FEC. When the target latency is on the order of one RTT, it is impossible to use congestion control schemes like BBR, since BBR has probing mechanisms that rely on temporarily inducing delay and amortizing the consequences of that over multiple RTTs. I think the first point illustrates nicely why protocols like RTP have low-level control over packetization, while the existing MoQ proposals defer it entirely to the QUIC stack.
NAME - that's super helpful. It helps us explain a few things - why we need to know this, in order to explain why we're shooting for One Protocol, and why we think the first three use cases in the draft are different (they're all RTPish), and why we're not looking at RTP in the BOF - right now, the draft just says AVTCORE is looking at RTP over QUIC, which really isn't much of a justification, engineering-wise.
Victor's points are well made, though I think picking the boundary of the number of round trips necessary to rely on standard QUIC loss detection is a challenge. 5 RTTs provides almost 5 opportunities to repair a loss, which in my experience is almost always enough. Similarly, I'd expect it's enough for BBR to complete various probing cycles. It's also important to understand what RTT we have in mind here. I think the RTT used to understand what domain you're in is approximately smoothed RTT (not min RTT), because the number of rounds for loss recovery or BBR gain cycling or Cubic packet conservation matter the most.
I agree that the numeric ranges are not useful when designing a protocol but they're useful enough as product requirements. However focusing on the RTT completely misses the point. Network latency involves fixed delays (min RTT) but most of it is caused by queuing (primarily congestion control). This includes any queues within the application, the network layer, intermediate routers, and even the receiver. You can think of latency as the "frame RTT" which is decoupled from the packet RTT. Of course the packet RTT is important, but it just doesn't factor in how much data has been queued. For example, it's just useless to talk about RTMP and HLS/DASH latency in terms of network RTTs. In my opinion, the problem with those protocols is that they impose unnecessary dependencies, making it slow to drop the bitrate to reduce queue sizes. Sending media over a single stream means that every frame depends on every previous frame regardless of the GoP structure (no frame dropping), and it also means that new GoPs are dependent on the previous GoPs (no skipping ahead). WebRTC avoids these unnecessary dependencies which is how it's able to rapidly respond to congestion to keep latency low. I've been working on a "latency theory" document if any of these ideas are resonating with people. I feel like it's too early though, and we should be focusing on the use-cases and requirements instead.
NAME - please let me know when you think it's not too early to focus on "latency theory". I'd love to know more (in particular, I'd love to know if I'd be able to contribute effectively to that important topic). Just filing this away for now, as you suggest.

Related discussion:
text: Our proposal is that "Media Over QUIC" discussions focus first on the use cases described in lm-media, which are Live Media Ingest (lmingest), Syndication (lmsynd), and Streaming (lmstream).  Our <del> reasoning is provided in usecaseanalysis. 5.1. </del> <ins> reasoning for this suggestion follows. </ins> Each of the above use cases in overallusecases fit into one of three classifications of solutions. <del> The first group, in interact, covering gaming (gaming), screen sharing (remdesk), and general video conferencing (vidconf), are largely covered by WebRTC and related protocols today.  Whilst there may be benefit in these use cases having a QUIC based protocol it may be more appropriate given the size of existing deployments to extend the WebRTC protocol and specifications.  Such work could start in a QUIC specific forum, but would likely need to take place in rtcweb and the W3C. </del> <ins> 5.1. The first group, Interactive Media, as described in interact, and covering gaming (gaming), screen sharing (remdesk), and general video conferencing (vidconf), are largely covered by RTP, often in conjunction with WebRTC WebRTC, and related protocols today. Whilst there may be benefit in these use cases having a QUIC based protocol it may be more appropriate given the size of existing deployments to extend the RTP protocols and specifications. 5.2. </ins> The second group of classifications, in lm-media, covering Live Media Ingest (lmingest), Live Media Syndication (lmsynd), and Live Media <del> Streaming (lmstream) are likely the use cases likely to benefit most from this work.  Existing protocols used such as HLS RFC8216 and DASH </del> <ins> Streaming (lmstream) are likely the use cases that will benefit most from this work. Existing ingest and streaming protocols such as HLS RFC8216 and DASH </ins> DASH are reaching limits towards how low they can reduce latency in live streaming and for scenarios where low-bitrate audio streams are <del> used add a significant amount of overheads compared to the media bitstream. </del> <ins> used, these protocols add a significant amount of overhead compared to the media bitstream itself. For this reason, we suggest that work on "Media Over QUIC" protocols target these use cases at this time. 5.3. </ins> The third group, od-media, covering On-Demand Media Ingest (od- ingest) and On-Demand Media streaming (od-stream) is unlikely to <del> benefit from work in this space.  Without notable latency requirements, protocols such as HLS and DASH largely meet the needs of this use case. </del> <ins> benefit from work in this space.  Without the same "Live Media" latency requirements that would motivate deployment of new protocols, existing protocols such as HLS and DASH are probably "good enough" to meet the needs of these use cases. This does not mean that existing protocols in this space are perfect. Segmented protocols such as HLS and DASH were developed to overcome the deficiencies of TCP, as used in HTTP/1.1 RFC7230 and HTTP/2 RFC7540, and do not make full use of the possible congestion window along the path from sender to receiver.  Other protocols in this space have their own deficiencies.  For example, RTSP RFC7826 does not have easy ways to add support for new media codecs. Our expectation is that these use cases will not drive work in the "Media Over QUIC" space, but as new protocols come into being, they may very well be taken up for these use cases as well. </ins> 6.