Code change:
1.1. <ins> The development of MoQT is driven by goals in a number of areas - specifically latency, the robustness of QUIC, workflow efficiency and relay support. </ins> 1.1.1. <del> In a perfect world, we could deliver live content at the same rate it is produced.  The end-to-end latency would be fixed and only subject to encoding and transmission delays.  Unfortunately, networks have variable throughput, primarily due to congestion. Attempting to deliver content encoded at a higher bitrate than the network can support causes queuing.  This queuing can occur anywhere in the path between the producer and consumer.  For example: the application, the OS socket, a wifi router, within an ISP, or generally anywhere in transit. If nothing is done, new data will be appended to the end of a growing queue and will take longer to arrive than their predecessors, increasing latency.  Our job is to minimize the growth of this queue, and if necessary, bypass the queue entirely by dropping content. The speed at which protocol can detect and respond to queuing determines the latency.  TCP-based protocols are simple, but are slow to detect congestion and suffer from head-of-line blocking.  UDP- based protocols can avoid queuing, but the application is now responsible for fragmentation, congestion control, retransmissions, receiver feedback, reassembly, and more. A goal of this draft is to get the best of both worlds: a simple protocol that can still rapidly detect and respond to congestion using QUIC streams. </del> <ins> HTTP Adaptive Streaming (HAS) has been successful at achieving scale although often at the cost of latency.  Latency is necessary to correct for variable network throughput.  Ideally live content is consumed at the same bitrate it is produced.  End-to-end latency would be fixed and only subject to encoding and transmission delays. Unfortunately, networks have variable throughput, primarily due to congestion.  Attempting to deliver content encoded at a higher bitrate than the network can support causes queuing along the path from producer to consumer.  The speed at which a protocol can detect and respond to queuing determines the overall latency.  TCP-based protocols are simple but are slow to detect congestion and suffer from head-of-line blocking.  UDP-based protocols can avoid queuing, but the application is now responsible for the complexity of fragmentation, congestion control, retransmissions, receiver feedback, reassembly, and more.  One goal of MoQTransport is to achieve the best of both these worlds: leverage the features of QUIC to create a simple yet flexible low latency protocol that can rapidly detect and respond to congestion. </ins> 1.1.1.1. <del> The live media protocol ecosystem is fragmented; each protocol has it's own niche.  Specialization is often a good thing, but we believe there's enough overlap to warrant consolidation. For example, a service might simultaneously ingest via WebRTC, SRT, RTMP, etc.  The same service might then simultaneously distribute via WebRTC, LL-HLS, HLS/DASH, etc.  Other similar live content would then be distributed other yet additional protocols: for example updates, chat, metadata, etc. This draft attempts to build a unified base transport protocol for media and similar use-cases.  Any live content can be fragmented into objects and annotated to achieve the intended behavior.  The goal is not to reinvent how content is encoded, just delivered. </del> <ins> The parallel nature of QUIC streams can provide improvements in the face of loss.  A goal of MoQT is to design a streaming protocol to leverage the transmission benefits afforded by parallel QUIC streams as well exercising options for flexible loss recovery.  Applying QUIC to HAS via HTTP/3 has not yet yielded generalized improvements in throughput.  One reason for this is that sending segments down a single QUIC stream still allows head-of-line blocking to occur. </ins> 1.1.1.2. <del> The prevailing belief is that UDP-based protocols are more expensive and don't "scale".  While it's true that UDP is more difficult to optimize than TCP, QUIC itself is proof that it is possible to reach performance parity. The ability to scale a live content transport actually depends on relay support: proxies, caches, CDNs, SFUs, etc.  The success of HTTP-based protocols is due to the ability for a HTTP CDN to cache and deduplicate requests. </del> <ins> Internet delivered media today has protocols optimized for ingest and separate protocols optimized for distribution.  This protocol switch in the distribution chain necessitates intermediary origins which re- package the media content.  While specialization can have its benefits, there are gains in efficiency to be had in not having to re-package content.  A goal of MoQT is to develop a single protocol which can be used for transmission from contribution to distribution. A related goal is the ability to support existing encoding and packaging schemas, both for backwards compatibility and for interoperability with the established content preparation ecosystem. </ins> <del> It's difficult to build a CDN for live protocols that were not designed with relays in mind.  This is the fatal flaw of many applications, as they relay on relays to perform bespoke parsing and decision making based on the contents. </del> <ins> 1.1.1.3. </ins> <del> A goal of this draft is to treat relays as first class citizens.  Any identification, reliability, ordering, prioritization, caching, etc is written to the wire in a header that is easy to parse.  This ensures that relays can easily route content and respond to congestion in a specified, deterministic manner. </del> <ins> An integral feature of a protocol being successful is its ability to deliver media at scale.  Greatest scale is achieved when third-party networks, independent of both the publisher and subscriber, can be leveraged to relay the content.  These relays must cache content for distribution efficiency while simultaneously routing content and deterministically responding to congestion in a multi-tenant network. A goal of MoQT is to treat relays as first-class citizens of the protocol and ensure that objects are structured such that information necessary for distribution is available to relays while the media content itself remains opaque and private. </ins> <del> 1.1.1.3. </del> <ins> 1.1.1.4. </ins> TODO: Add motivation text regarding bw management techniques in response to congestion.  Also refer to priority-congestion for

Related discussion:
text: NAME I think you added this TODO but it got removed in the editorial pass, are you good with that?
Yes, we can remove this. We will certainly revisit the issue later, because this is a thorny subject. For example, we assume that "objects MUST not depend from objects in the group that have a higher priority code or a higher object ID" -- object at P2 does not depend on another object at P3, object number 1000 cannot depend on object number 2001. That much has consensus, but it is a negative statement.