jiebi/CodeConvo huggingface dataset:
Code change:
It's likely that only NAME and I will care about this, but I think it matters :grin:

Related discussion:
text: by signalling of connection inforation (bandwidth, latency) based on data sent by the receiver. <del> 4.6. </del> <ins> 4.2.2. </ins> *Senders/Receivers*: One to One *Bi-directional*: No *Latency*: <del> Ultra-Low to Low </del> <ins> Ull-200 to Ultra-Low </ins> Where media is sent onwards to another platform for further distribution.  The media may be compressed down to a bitrate lower than source, but larger than final distribution output.  Streams may be redundant with failover mechanisms in place. <del> 4.7. </del> <ins> 4.2.3. *Senders/Receivers*: One to Many *Bi-directional*: No *Latency*: Ull-200 to Ultra-Low Where media is received from a live broadcast or stream.  This may comprise of multiple audio or video outputs with different codecs or bitrates.  This may also include other types of media essence such as subtitles or timing signalling information (e.g. markers to indicate change of behaviour in client such as advertisement breaks).  The use of "live rewind" where a window of media behind the live edge can be made available for clients to playback, either because the local player falls behind edge or because the viewer wishes to play back from a point in the past. 4.3. 4.3.1. ** James, can you fill this section in?** 4.3.2. </ins> *Senders/Receivers*: One to Many *Bi-directional*: No *Latency*: On Demand
Code change:
It's likely that only NAME and I will care about this, but I think it matters :grin:

Related discussion:
text: 5. Our proposal is that "Media Over QUIC" discussions focus first on the <del> use cases for Live Media Contribution (lmcont), Syndication (lmsynd), and Streaming (lmstream).  Our reasoning is provided in usecaseanalysis. </del> <ins> use cases described in lm-media, which are Live Media Ingest (lmingest), Syndication (lmsynd), and Streaming (lmstream).  Our reasoning is provided in usecaseanalysis. </ins> 5.1. Each of the above use cases in overallusecases fit into one of three classifications of solutions. <del> The first group, covering gaming (gaming), screen sharing (remdesk), and general video conferencing (vidconf), are largely covered by WebRTC and related protocols today.  Whilst there may be benefit in these use cases having a QUIC based protocol it may be more appropriate given the size of existing deployments to extend the WebRTC protocol and specifications.  Such work could start in a QUIC specific forum, but would likely need to take place in rtcweb and the W3C. The second group of classifications, covering Live Media Contribution (lmcont), Syndication (lmsynd), and Streaming (lmstream) are likely the use cases likely to benefit most from this work.  Existing protocols used such as HLS RFC8216 and DASH DASH are reaching limits towards how low they can reduce latency in live streaming and for scenarios where low-bitrate audio streams are used add a significant amount of overheads compared to the media bitstream. On-Demand media streaming (odstream) is unlikely to benefit from work in this space.  Without notable latency requirements, protocols such as HLS and DASH largely meet the needs of this use case. </del> <ins> The first group, in interact, covering gaming (gaming), screen sharing (remdesk), and general video conferencing (vidconf), are largely covered by WebRTC and related protocols today.  Whilst there may be benefit in these use cases having a QUIC based protocol it may be more appropriate given the size of existing deployments to extend the WebRTC protocol and specifications.  Such work could start in a QUIC specific forum, but would likely need to take place in rtcweb and the W3C. The second group of classifications, in lm-media, covering Live Media Ingest (lmingest), Live Media Syndication (lmsynd), and Live Media Streaming (lmstream) are likely the use cases likely to benefit most from this work.  Existing protocols used such as HLS RFC8216 and DASH DASH are reaching limits towards how low they can reduce latency in live streaming and for scenarios where low-bitrate audio streams are used add a significant amount of overheads compared to the media bitstream. The third group, od-media, covering On-Demand Media Ingest (od- ingest) and On-Demand Media streaming (od-stream) is unlikely to benefit from work in this space.  Without notable latency requirements, protocols such as HLS and DASH largely meet the needs of this use case. </ins> 6.
Code change:
We should talk about whether the MOPS latency constraints make sense, or whether we should stop suffering and switch to something that's not about transport latency, but more about end-to-end workflow duration, which is what I think we're talking about in the "On Demand Media" section. But we can do that another day.
I think it's hard to really define latency for on demand for a whole host of reasons: The non-functional requirements for a system to process an on demand asset can vary dramatically. For example, it's common for news clips to have an SLA of clip duration to ingest, transcode, deliver, and be playable. Whereas for high resolution content, this stage of ingest and processing can take many multiples of duration and may be done hours/days in advance of its availability to playback. It's not really live, so the measurement of "latency" is a bit weird here. The latency between the origin storage serving the media to presentation on screen is, in general irrelevant from a playback perspective provided it doesn't stall out playback due to poor network conditions. Throughput and jitter have a greater affect.

Related discussion:
text: 4.3.1. <del> ** James, can you fill this section in?** </del> <ins> *Senders/Receivers*: One to Many *Bi-directional*: No *Latency*: On Demand Where media is ingested and processed for a system to later serve it to clients as on-demand media.  This may be media captured from live output or provided as a pre-recorded source, and may optionally be transcoded upon ingest. </ins> 4.3.2.
Code change:
I propose defining latencies less than 50 ms as near real-time latencies. These latencies can be used by musicians to play together in sync. And I guess the human ear or eye would mostly not notice any delay below 50 ms. Might be worth doing a bit of research around the topic to refine the ranges though. For instance, in this paper (URL) they conclude: In another source (URL) the following is defined: 150ms target performance 13ms > lower detectable limit
< 200 ms - comfortable latencies for conversation.
Apologies for not looking at this earlier, I've had to prioritise other work recently. Given that our draft and these values are an extension of , could you please also include the references and elaboration like you have in the PR as I think it will help quell any further bikeshedding on the subject.
The MOPS document now mentions near-realtime latencies (see URL), but does not define the exact values. Likely this PR still makes sense, but now as an attempt to define those type of latencies.

Related discussion:
text: interactive media may have requirements that are significantly less than "ultra-low latency".  Within this document, we are also using <del> Ull-50 (less than 50 ms) </del> <ins> near real-time (less than 50 ms) </ins> Ull-200 (less than 200 ms) Perhaps obviously, these last two latency bands are the shortened
Code change:
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.

Related discussion:
text: Abstract <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 or WebTransport. </ins> Note to Readers
Code change:
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.

Related discussion:
text: 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 <del> mechanisms that rely on temporarily inducing delay and amortizing the consequences of that over multiple RTTs. </del> <ins> mechanisms that rely on temporarily inducing delay, but these mechanisms can then amortize the consequences of induced delay over multiple RTTs. </ins> <del> 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. </del> <ins> This may help to explain why interactive use cases have typically relied on protocols such as RTP RFC3550, which provide low-level control of packetization and transmission, and make no provision for retransmission. </ins> <del> 4.1.1. </del> <ins> 3.1.1. </ins> Where media is received, and user inputs are sent by the client. <del> This may also include the client receiving other types of signalling, </del> <ins> This may also include the client receiving other types of signaling, </ins> such as triggers for haptic feedback.  This may also carry media from the client such as microphone audio for in-game chat with other players. <del> 4.1.2. </del> <ins> 3.1.2. </ins> Where media is received, and user inputs are sent by the client. <del> Latency requirements with this usecase are marginally different than </del> <ins> Latency requirements with this use case are marginally different than </ins> the gaming use case.  This may also include signalling and/or transmitting of files or devices connected to the user's computer. <del> 4.1.3. </del> <ins> 3.1.3. </ins> Where media is both sent and received; This may include audio from both microphone(s) or other inputs, or may include "screen sharing"
Code change:
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.

Related discussion:
text: such as audio, but other media types in this use case have much more stringent latency targets. <del> 4.2. </del> <ins> 3.2. </ins> For the video conferencing/telephony use case, there can be additional scenarios where the audience greatly outnumbers the concurrent active participants, but any member of the audience could participate.  As this has a much larger total number of participants - as many as Live Media Streaming lmstream, but with the bi- <del> directionality of confercing, this should be considered a "hybrid". </del> <ins> directionality of conferencing, this should be considered a "hybrid". </ins> <del> 4.3. </del> <ins> 3.3. </ins> The use cases in this section, unlike the use cases described in interact, still have "humans in the loop", but these humans expect
Code change:
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.

Related discussion:
text: video is being produced "live" and sent to a platform for syndication and distribution. <del> 4.3.1. </del> <ins> 3.3.1. </ins> Where media is received from a source for onwards handling into a distribution platform.  The media may comprise of multiple audio and/ or video sources.  Bitrates may either be static or set dynamically <del> by signalling of connection inforation (bandwidth, latency) based on </del> <ins> by signaling of connection information (bandwidth, latency) based on </ins> data sent by the receiver. <del> 4.3.2. </del> <ins> 3.3.2. </ins> Where media is sent onwards to another platform for further distribution.  The media may be compressed down to a bitrate lower than source, but larger than final distribution output.  Streams may be redundant with failover mechanisms in place. <del> 4.3.3. </del> <ins> 3.3.3. </ins> Where media is received from a live broadcast or stream.  This may comprise of multiple audio or video outputs with different codecs or
Code change:
NAME could you take a look at this? I know everyone's thinking has changed on details, but we can capture those changes as the working group converges.
The subsections should be Publishing Media Naming or Identification Packaging Media Media Consumption Relays/Caches End to End Security This is only a starting point, of course, but , and it's easier to keep track of them if the document subsections match, at least for now.
NAME - ISTM that the contain a lot of material that might better be put in another section. I'll work through that before we talk (next week, right?), but please keep this note in mind, so we can fix what I get wrong. Also - ISTM that we really do need a "specific protocol considerations" requirement section, to capture things like streams/datagrams, WebTransport/H3/QUIC, one MOQ protocol, etc. I'll add that in the PR for this issue as well.
NAME most of the sections had some beginning text (and I can't remember who wrote it - was it you?). I'm copying the bullets from NAME slides into each section as a starting point. I'm not sure whether deleting the beginning text is the right thing to do, because it might or might not match the resulting subsections' contents, and of course the new subsections don't have beginning text because they didn't exist before, but let's talk about that, next week.

Related discussion:
text: they consider implementation and deployment of systems that rely on the MOQ protocol. <del> *Note: the initial high-level organization for this section is taken from Suhas Nandakumar's presentation, "Progressing MOQ" Prog-MOQ, at the October 2022 MOQ virtual interim meeting, which was in turn taken from the MOQ working group charter MOQ-charter.  We think this is a reasonable starting point.  We won't be surprised to see the high- level structure change a bit as things develop, but we didn't want to have this section COMPLETELY blank when we request working group adoption. TODO: Describe overall, high level requirements that we previously stated in earlier versions of this document. </del> 4.2. <ins> 4.2.1. 4.2.2. 4.2.3. 4.2.4. 4.2.5. 4.3. </ins> Many of the use cases have bi-directional flows of media, with clients both sending and receiving media concurrently, thus the protocol should have a unified approach in connection negotiation and
Code change:
NAME could you take a look at this? I know everyone's thinking has changed on details, but we can capture those changes as the working group converges.
The subsections should be Publishing Media Naming or Identification Packaging Media Media Consumption Relays/Caches End to End Security This is only a starting point, of course, but , and it's easier to keep track of them if the document subsections match, at least for now.
NAME - ISTM that the contain a lot of material that might better be put in another section. I'll work through that before we talk (next week, right?), but please keep this note in mind, so we can fix what I get wrong. Also - ISTM that we really do need a "specific protocol considerations" requirement section, to capture things like streams/datagrams, WebTransport/H3/QUIC, one MOQ protocol, etc. I'll add that in the PR for this issue as well.
NAME most of the sections had some beginning text (and I can't remember who wrote it - was it you?). I'm copying the bullets from NAME slides into each section as a starting point. I'm not sure whether deleting the beginning text is the right thing to do, because it might or might not match the resulting subsections' contents, and of course the new subsections don't have beginning text because they didn't exist before, but let's talk about that, next week.

Related discussion:
text: is unsupported (e.g. a live media server signalling it does not support receiving from a given client). <del> 4.3. </del> In the initiation of a session both client and server must perform negotiation in order to agree upon a variety of details before media can move in any direction:
Code change:
NAME could you take a look at this? I know everyone's thinking has changed on details, but we can capture those changes as the working group converges.
The subsections should be Publishing Media Naming or Identification Packaging Media Media Consumption Relays/Caches End to End Security This is only a starting point, of course, but , and it's easier to keep track of them if the document subsections match, at least for now.
NAME - ISTM that the contain a lot of material that might better be put in another section. I'll work through that before we talk (next week, right?), but please keep this note in mind, so we can fix what I get wrong. Also - ISTM that we really do need a "specific protocol considerations" requirement section, to capture things like streams/datagrams, WebTransport/H3/QUIC, one MOQ protocol, etc. I'll add that in the PR for this issue as well.
NAME most of the sections had some beginning text (and I can't remember who wrote it - was it you?). I'm copying the bullets from NAME slides into each section as a starting point. I'm not sure whether deleting the beginning text is the right thing to do, because it might or might not match the resulting subsections' contents, and of course the new subsections don't have beginning text because they didn't exist before, but let's talk about that, next week.

Related discussion:
text: accepted? Re-negotiation in an existing protocol should be supported to allow <del> changes in what is being sent of received. </del> <ins> changes in what is being sent or received. 4.3.1. 4.3.2. 4.3.3. 4.3.4. 4.3.5. 4.3.6. 4.3.7. </ins> 4.4.
Code change:
NAME could you take a look at this? I know everyone's thinking has changed on details, but we can capture those changes as the working group converges.
The subsections should be Publishing Media Naming or Identification Packaging Media Media Consumption Relays/Caches End to End Security This is only a starting point, of course, but , and it's easier to keep track of them if the document subsections match, at least for now.
NAME - ISTM that the contain a lot of material that might better be put in another section. I'll work through that before we talk (next week, right?), but please keep this note in mind, so we can fix what I get wrong. Also - ISTM that we really do need a "specific protocol considerations" requirement section, to capture things like streams/datagrams, WebTransport/H3/QUIC, one MOQ protocol, etc. I'll add that in the PR for this issue as well.
NAME most of the sections had some beginning text (and I can't remember who wrote it - was it you?). I'm copying the bullets from NAME slides into each section as a starting point. I'm not sure whether deleting the beginning text is the right thing to do, because it might or might not match the resulting subsections' contents, and of course the new subsections don't have beginning text because they didn't exist before, but let's talk about that, next week.

Related discussion:
text: should be supported, but further extended metadata of the contents of the media or its ontology should not be supported. <ins> 4.4.1. 4.4.2. 4.4.3. 4.4.4. 4.4.5. </ins> 4.5. Packaging of media describes how encapsulation of media to carry the
Code change:
NAME could you take a look at this? I know everyone's thinking has changed on details, but we can capture those changes as the working group converges.
The subsections should be Publishing Media Naming or Identification Packaging Media Media Consumption Relays/Caches End to End Security This is only a starting point, of course, but , and it's easier to keep track of them if the document subsections match, at least for now.
NAME - ISTM that the contain a lot of material that might better be put in another section. I'll work through that before we talk (next week, right?), but please keep this note in mind, so we can fix what I get wrong. Also - ISTM that we really do need a "specific protocol considerations" requirement section, to capture things like streams/datagrams, WebTransport/H3/QUIC, one MOQ protocol, etc. I'll add that in the PR for this issue as well.
NAME most of the sections had some beginning text (and I can't remember who wrote it - was it you?). I'm copying the bullets from NAME slides into each section as a starting point. I'm not sure whether deleting the beginning text is the right thing to do, because it might or might not match the resulting subsections' contents, and of course the new subsections don't have beginning text because they didn't exist before, but let's talk about that, next week.

Related discussion:
text: packaging of media, taking into consideration the various technical trade offs that each provide. <ins> 4.5.1. 4.5.2. 4.5.3. </ins> 4.6. <ins> 4.6.1. 4.6.2. 4.6.3. 4.7. 4.7.1. 4.7.2. 4.7.3. 4.7.4. 4.7.5. 4.8. </ins> End-to-end security describes the use of encryption of the media stream(s) to provide confidentiality in the presence of unauthorized intermediates or observers and prevent or restrict ability to decrypt
Code change:
NAME could you take a look at this? I know everyone's thinking has changed on details, but we can capture those changes as the working group converges.
The subsections should be Publishing Media Naming or Identification Packaging Media Media Consumption Relays/Caches End to End Security This is only a starting point, of course, but , and it's easier to keep track of them if the document subsections match, at least for now.
NAME - ISTM that the contain a lot of material that might better be put in another section. I'll work through that before we talk (next week, right?), but please keep this note in mind, so we can fix what I get wrong. Also - ISTM that we really do need a "specific protocol considerations" requirement section, to capture things like streams/datagrams, WebTransport/H3/QUIC, one MOQ protocol, etc. I'll add that in the PR for this issue as well.
NAME most of the sections had some beginning text (and I can't remember who wrote it - was it you?). I'm copying the bullets from NAME slides into each section as a starting point. I'm not sure whether deleting the beginning text is the right thing to do, because it might or might not match the resulting subsections' contents, and of course the new subsections don't have beginning text because they didn't exist before, but let's talk about that, next week.

Related discussion:
text: security is "sender-to-receiver", but some "ends" may not be either senders or ultimate receivers, from a certain point of view. <ins> 4.8.1. </ins> 5. This document makes no requests of IANA.