Code change:
6. <del> Even a cursory examination of the existing proposals listed in priorart shows that there are fundamental differences in the approaches being used.  This sction is intended to "up-level" the conversation beyond specific protocols, so that we can more likely agree on what is important for protocol design work. Please note that the considerations in this section are focused especially on the use cases described in lm-media, although other use cases are mentioned for comparison and contrast. 6.1. The discussion in considerations is less mature than in most other sections of this document.  The good news is that this section is fertile ground for people who would like to contribute to future revisions of this document.  Comments are even more welcome for this section than for the rest of the document, for which they are welcome.  The authors suggest that high-level comments are most appropriate at this time. 6.2. When initiating a media session, both the sender and receiver will need to agree on the codecs, bitrates, resolution, and other media details based on capabilities and preferences.  This agreement needs to take place before commencing media transmission, but might also take place during media transmission, perhaps as a result of changes to device output or network conditions (such as reduction in available network bandwidth). It may be prefered to use existing ecosystem for such purposes, e.g. SDP RFC4566. 6.3. Support for a nominal latency appropriate for the use cases that are in scope should be achievable, with consideration for the minimum buffer that a receiver playing content may need to handle congestion, packet loss, and other degradation in network quality. 6.4. Handling of migration of a session between hosts, either of sender or receiver should be supported.  This may either happen because the sender is undergoing maintenence or a rebalancing of resource, because the either is experiencing a change in network connectivity (such as a device moving from WiFi to cellular connectivity) or other reasons. This may depend on QUIC capabilities such as I-D.draft-ietf-quic- multipath but support for full QUIC operation over multiple paths between senders and receivers is by no means essential. 6.5. An appropriate congestion control mechanism will depend upon the use cases under consideration. It's worth remembering that we have more experience with QUIC carrying HTTP traffic than with any other type of application at this time, and consequently, we have more experience with congestion control mechanisms such as NewReno RFC9002, Cubic RFC8312, and BBR I- D.draft-cardwell-iccrg-bbr-congestion-control being used with QUIC than with any other congestion control mechanisms.  These congestion control mechanisms may also be appropriate for the on-demand use cases described in od-media. Conversely, for the interactive use cases described in interact, these congestion control mechanisms are very likely inappropriate, especially when QUIC is being used with a Media Transport Protocol such as RTP, which provides its own congestion control mechanism, and which does not seem to interact well with a second, QUIC-level congestion control mechanism.  Congestion control mechanisms such as SCReAM RFC8298 or NADA RFC8698 may be more appropriate for media. "Congestion Control Requirements for Interactive Real-Time Media" RFC8836 is a useful reference. Awkwardly, the live media use cases described in lm-media live somewhere in the middle, and work will be needed to understand the characteristics of an appropriate congestion control mechanism for these use cases. 6.6. TODO: confirm scope of this draft to describe lossless media transport, lossy media transport, or both lossless and lossy transport. 6.7. Media should be able to flow in either direction from client to server or vice-versa, either individually or concurrently but should only be negotiated at the start of the session. 6.8. TODO: Unsure of the importance of this consideration for live media use cases.  If this is critical, we have to consider two things: WebTransport supports HTTP/2, are we going to explicitly exclude it? Also, WebTransport I-D.draft-ietf-webtrans-overview has normative language around congestion control, which may be at odds with the considerations described in acc. 6.9. In order to allow hosts to authenticate one another, capabilities beyond what QUIC provides may be necessary.  This should be kept simple but robust in nature to prevent attacks like credential brute- forcing. TODO: More details are required here 6.10. Most of the discussion of protocol work in this document has avoided mentioning capabilities that may be useful for some use cases, but seem to imply the need for extensions to the QUIC protocol, beyond what is already being considered in the IETF QUIC working group. These are included in this section, for completeness' sake. 6.10.1. From Section 8.2 of RFC9000: Path validation is not designed as a NAT traversal mechanism. Though the mechanism described here might be effective for the creation of NAT bindings that support NAT traversal, the expectation is that one endpoint is able to receive packets without first having sent a packet on that path.  Effective NAT traversal needs additional synchronization mechanisms that are not provided here. Although there are use cases that would benefit from a mechanism for NAT traversal, a QUIC protocol extention would be needed to support those use cases. 6.10.2. Even if multicast and other network broadcasting capabilities are often used in delivering media in our use cases, QUIC doesn't yet support multicast, and a QUIC protocol extension would be needed to do so.  In addition, the inclusion of multicast would introduce more complexity in both the specification and client implimentations.  On the other hand, UDP multicast may be considered as the last mile delivery transport outside of QUIC transport, thus it would be beneficial for a protocol to provide such an opportunity (e.g.  RTP/ QUIC -> RTP/UDP). </del> <ins> TODO: Quite a lot, really ... </ins> 7.

Related discussion:
text: If we renamed the document as "Live Media Over QUIC", it would be more accurate, and the BOF proponents could point to this draft and ask people with other use cases if their use cases overlap with the live media use cases, perhaps allowing the BOF to recommend doing the live media use cases in this draft, and inviting people to provide comments on this draft explaining their use cases, so the IESG would know what to do with them. Your thoughts?
I don't object to the name change but I don't feel strongly.
That name works for me too.
We should revisit after the BOF, when we know what the scope of the document will be. :sunglasses:
So, this is slightly more complicated than I had hoped. The use cases in the draft span "Media Over QUIC". The considerations (and, if we get that far, requirements) in the draft only cover "LIVE Media Over QUIC". So, let's leave this one open, until we find out the right thing to do, and then we can Do The Right Thing. :innocent:
I would propose we rename (again) to "Media over QUIC Use Cases and Requirements", for a few reasons: Scope of use cases that the WG will work on isn't yet settled, and it's likely that we may need to cover some (but not all) interactive use cases as well as hybrid interactive/live. I still think we should set the protocol requirements in the document - this frees up the charter to describe scope and milestone, and our draft (if WG adopted) to set the use cases and what we will require of the deliverables. If WG adopted, the details of what is in and out can be made via WG consensus. This follows a similar title format to and other documents like it. NAME thoughts?