Code change:
1. <del> This document describes use cases that have been discussed in the IETF community under the banner of "Media Over QUIC", provides analysis about those use cases, recommends a subset of use cases that cover live media ingest, syndication, and streaming for further exploration, and describes requirements that should guide the design of protocols to satisfy these use cases. </del> <ins> This document describes use cases and requirements that guide the specification of a simple, low-latency media delivery solution for ingest and distribution of media, using either the QUIC protocol RFC9000 or WebTransport WebTrans-charter. This document describes the chartered MOQ-charter use cases that guide development of a simple, low-latency media delivery solution for ingest and distribution of media, and the requirements for this solution that result from these use cases. </ins> 1.1. <del> Our proposal is to focus on live media use cases, as described in propscope, rather than on interactive media use cases or on-demand use cases. The reasoning behind this proposal can be found in analy-interact. The requirements for protocol work to satisfy the proposed use cases can be found in req-sec. Most of the rest of this document provides background for these sections. 1.2. It is not the purpose of this document to argue against proposals for work on media applications that do not involve QUIC.  Such proposals are simply out of scope for this document. When work on the QUIC protocol (RFC9000) was chartered (QUIC-goals), the key goals for QUIC were: Minimizing connection establishment and overall transport latency for applications, starting with HTTP, Providing multiplexing without head-of-line blocking, Requiring only changes to path endpoints to enable deployment, Enabling multipath and forward error correction extensions, and Providing always-secure transport, using TLS 1.3 by default. These goals were chosen with HTTP (I-D.draft-ietf-quic-http) in mind. While work on "QUIC version 1" (version codepoint 0x00000001) was underway, protocol designers considered potential advantages of the QUIC protocol for other applications.  In addition to the key goals for HTTP applications, these advantages were immediately apparent for at least some media applications: QUIC endpoints can create bidirectional or unidirectional ordered byte streams. QUIC will automatically handle congestion control, packet loss, and reordering for stream data. QUIC streams allow multiple media streams to share congestion and flow control without otherwise blocking each other. QUIC streams also allow partial reliability, since either the sender or receiver can terminate the stream early without affecting the overall connection. With the DATAGRAM extension (I-D.draft-ietf-quic-datagram), further partially reliable models are possible, and applications can send congestion controlled datagrams below the MTU size. QUIC connections are established using an ALPN. QUIC endpoints can choose and change their connection ID. QUIC endpoints can migrate IP address without breaking the connection. Because QUIC is encapsulated in UDP, QUIC implementations can run in user space, rather than in kernel space, as TCP typically does. This allows more room for extensible APIs between application and transport, allowing more rapid implementation and deployment of new congestion control, retransmission, and prioritization mechanisms. QUIC is supported in browsers via HTTP/3 or WebTransport. With WebTransport, it is possible to write libraries or applications in JavaScript. The specific advantages of interest may vary from use case to use case, but these advantages justify further investigation of "Media Over QUIC". </del> <ins> This version of the document is intended to provide the MOQ working group with a starting point for work on the "Use Cases and Requirements document" milestone.  The update implements the work plan described in MOQ-ucr.  The authors intend to request MOQ working group adoption after IETF 115, so we can begin work on these topics in earnest. </ins> 2. <del> 2.1. Protocol developers have been considering the implications of the QUIC protocol (RFC9000) for media transport for several years, resulting in a large number of possible meanings of the term "Media Over QUIC", or "MOQ".  As of this writing, "Media Over QUIC" has had at least these meanings: any kind of media carried directly over the QUIC protocol, as a QUIC payload any kind of media carried indirectly over the QUIC protocol, as an RTP payload (RFC3550) any kind of media carried indirectly over the QUIC protocol, as an HTTP/3 payload any kind of media carried indirectly over the QUIC protocol, as a WebTransport payload the encapsulation of any Media Transport Protocol in a QUIC payload an IETF mailing list (MOQ-ml), which was requested "... for discussion of video ingest and distribution protocols that use QUIC as the underlying transport", although discussion of other Media Over QUIC proposals have also been discussed there. There may be IETF participants using other meanings as well. As of this writing, the second bullet ("any kind of media carried indirectly over the QUIC protocol, as an RTP payload"), seems to be in scope for the IETF AVTCORE working group, and was discussed at some length at the February 2022 AVTCORE working group meeting AVTCORE-2022-02, although no drafts in this space have yet been adopted by the AVTCORE working group. 2.2. }The "Operational Considerations for Streaming Media" document (I- D.draft-ietf-mops-streaming-opcons) described a range of latencies of interest to streaming media providers, as ultra low-latency (less than 1 second) low-latency live (less than 10 seconds) non-low-latency live (10 seconds to a few minutes) on-demand (hours or more) Because the IETF Media Over QUIC community now expresses interest in interactive media interact and live media lm-media} use cases will have requirements that are significantly less than the "streaming media"-defined "ultra-low latency". Within this document, we are using near real-time (less than 50 ms) Ull-200 (less than 200 ms) Perhaps obviously, these last two latency bands are the shortened form of "ultra-low latency - 50 ms" and "ultra-low-latency - 200 ms". Perhaps less obviously, bikeshedding on better names and more useful values is welcomed. </del> <ins> (To Do) </ins> 3. <del> Several draft specifications have been proposed which either encapsulate existing Media Transport Protocols in QUIC (I-D.draft- sharabayko-srt-over-quic), make use of RTP, RTCP, and SDP (I-D.draft- engelbart-rtp-over-quic) or define their own new Media Transport Protocol on top of QUIC.  Some have already seen deployment into the wild (e.g.  I-D.draft-kpugin-rush, I-D.draft-lcurley-warp) where as others are unconfirmed.  Whilst most just focus on defining wire format, I-D.draft-jennings-moq-quicr-arch defines an architecture using a pub/sub model for both producers and consumers. 3.1. Some use QUIC Datagram frames, while others use QUIC streams. All drafts take differing approaches to flow/stream identification and management.  Some address congestion control and others just defer this to QUIC to handle. Some drafts specify ALPN identification, while others do not. 4. </del> Our goal in this section is to understand the range of use cases that <del> have been proposed for "Media Over QUIC". Although some of the use cases described in this section came out of "RTP over QUIC" proposals, they are worth considering in the broader "Media Over QUIC" context, and may be especially relevant to MOQ, depending on whether "RTP over QUIC" requires major changes to RTP and RTCP, in order to meet the requirements arising out of the corresponding use cases. </del> <ins> are in scope for "Media Over QUIC" MOQ-charter. </ins> <del> An early draft in the "media over QUIC" space, I-D.draft-rtpfolks- quic-rtp-over-quic, defined several key use cases.  Some of the following use cases have been inspired by that document, and others have come from discussions with the wider MOQ community (among other places, a side meeting at IETF 112). For each use case in this section, we also define </del> <ins> For each use case in this section, we also describe </ins> the number of senders or receiver in a given session transmitting distinct streams, <del> whether a session has bi-direction flows of media from senders and receivers, and the expected lowest latency requirements using the definitions specified in term. </del> <ins> whether a session has bi-directional flows of media from senders and receivers, and the worst-case expected RTT requirements. </ins> It is likely that we should add other characteristics, as we come to understand them. <del> 4.1. </del> <ins> 3.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

Related discussion:
text: NAME - I think this version is ready for submission as -03, when the submission window reopens during IETF 115. Please let me know what you think.
It would help people contribute to this document if there are blank sections in outline form, and we will be less likely to miss critical stuff.
The IETF 115 proposal to the working group is to use the approved charter as the high level outline for the Requirements section.