Code change:
4.1. <ins> The use cases described in this section have one particular attribute in common - the target latency for these cases are on the order of one or two RTTs.  In order to meet those targets, it is not possible to rely on protocol mechanisms that require multiple RTTs to function effectively.  For example, When the target latency is on the order of one RTT, it makes sense to use FEC RFC6363 and codec-level packet loss concealment RFC6716, rather than selectively retransmitting only lost packets. These mechanisms use more bytes, but do not require multiple RTTs in order to recover from packet loss. When the target latency is on the order of one RTT, it is impossible to use congestion control schemes like BBR I-D.draft- cardwell-iccrg-bbr-congestion-control, since BBR has probing mechanisms that rely on temporarily inducing delay and amortizing the consequences of that over multiple RTTs. This may help to explain why these use cases often rely on protocols such as RTP RFC3550, which provide low-level control of packetization and transmission. </ins> 4.1.1. *Senders/Receivers*: One to One *Bi-directional*: Yes *Latency*:

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