Code change:
4.1.3. *Senders/Receivers*: Many to Many *Bi-directional*: Yes *Latency*: <del> Ull-200 </del> <ins> Ull-50 to Ull-200 </ins> Where media is both sent and received; This may include audio from both microphone(s) or other inputs, or may include "screen sharing" or inclusion of other content such as slide, document, or video presentation.  This may be done as client/server, or peer to peer <del> with a many to many relationship of both senders and receivers. </del> <ins> with a many to many relationship of both senders and receivers.  The target for latency may be as large as Ull-200 for some media types such as audio, but other media types in this use case have much more stringent latency targets. </ins> 4.2. <ins> The use cases in this section, unlike the use cases described in interact, still have "humans in the loop", but these humans expect media to be "responsive", where the responsiveness is more on the order of 5 to 10 RTTs.  This allows the use of protocol mechanisms that require more than one or two RTTs - as noted in interact, end- to-end recovery from packet loss and congestion avoidance are two such protocol mechanisms that can be used with Live Media. To illustrate the difference, the responsiveness expected with videoconferencing is much greater than watching a video, even if the video is being produced "live" and sent to a platform for syndication and distribution. </ins> 4.2.1. *Senders/Receivers*: One to One *Bi-directional*: No *Latency*:

Related discussion:
text: 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).