jiebi/CodeConvo huggingface dataset:
bandwidth-delay product (see RFC7323). Even with full awareness of the current bandwidth-delay product, <del> implementation of flow control can be difficult.  When using flow control, the receiver MUST read from the TCP receive buffer in a timely fashion.  Failure to do so could lead to a deadlock when </del> <ins> implementation of flow control can be difficult.  Endpoints MUST read and process HTTP/2 frames from the TCP receive buffer as soon as data is available.  Failure to read promptly could lead to a deadlock when </ins> critical frames, such as WINDOW_UPDATE, are not read and acted upon. <ins> Reading frames promptly does not expose endpoints to resource exhaustion attacks as HTTP/2 flow control limits resource commitments. </ins> 5.2.3.
An endpoint that encounters a connection error SHOULD first send a GOAWAY frame (GOAWAY) with the stream identifier of the last stream that it successfully received from its peer.  The GOAWAY frame <del> includes an error code that indicates why the connection is </del> <ins> includes an ErrorCodes that indicates why the connection is </ins> terminating.  After sending the GOAWAY frame for an error condition, the endpoint MUST close the TCP connection.
request.  Similarly, intermediaries might forward incomplete messages before detecting errors.  A server MAY generate a final response before receiving an entire request when the response does not depend <del> on the remainder of the request being correct.  A server or intermediary MAY use RST_STREAM -- with a code other than REFUSED_STREAM -- to abort a stream if a malformed request or response is received. </del> <ins> on the remainder of the request being correct. </ins> These requirements are intended to protect against several types of common attacks against HTTP; they are deliberately strict because
to "open".  A PUSH_PROMISE frame will transition the server-initiated stream identified by the "Promised Stream ID" field in the frame payload from "idle" to "reserved".  When a stream transitions out of <del> the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed".  That is, an endpoint may skip a stream identifier, with the effect being that the skipped stream is immediately closed. </del> <ins> the "idle" state, all "idle" streams that might have been opened by the peer with a lower-valued stream identifier immediately transition to "closed".  That is, an endpoint may skip a stream identifier, with the effect being that the skipped stream is immediately closed. </ins> Stream identifiers cannot be reused.  Long-lived connections can result in an endpoint exhausting the available range of stream
when the peer has received and applied the changed parameter values. In order to provide such synchronization timepoints, the recipient of a SETTINGS frame in which the ACK flag is not set MUST apply the <del> updated settings as soon as possible upon receipt. </del> <ins> updated settings as soon as possible upon receipt.  SETTINGS frames are acknowledged in the order in which they are received. </ins> The values in the SETTINGS frame MUST be processed in the order they appear, with no other frame processing between values.  Unsupported
If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a <del> ConnectionErrorHandler of type SETTINGS_TIMEOUT. </del> <ins> ConnectionErrorHandler of type SETTINGS_TIMEOUT.  In setting a timeout, some allowance need to be made for processing delays at the peer; a timeout that is solely based on the round trip time between endpoints might result in spurious errors. </ins> 6.6.
The receiver of a frame sends a WINDOW_UPDATE frame as it consumes data and frees up space in flow-control windows.  Separate WINDOW_UPDATE frames are sent for the stream- and connection-level <del> flow-control windows. </del> <ins> flow-control windows.  Receivers are advised to have mechanisms in place to avoid sending WINDOW_UPDATE frames with very small increments; see RFC1122. </ins> A sender that receives a WINDOW_UPDATE frame updates the corresponding window by the amount specified in the frame.
of a header field does not equal the sum of the DATA frame payload lengths <del> that form the content.  A response that is defined to have no content, as described in HTTP, can have a non-zero </del> <ins> that form the content, unless the message is defined as having no content.  For example, 204 or 304 responses contain no content, as does the response to a HEAD request.  A response that is defined to have no content, as described in HTTP, MAY have a non-zero </ins> header field, even though no content is included in DATA frames.
A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit the number of responses that can be concurrently pushed by a server. <del> Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables server push by preventing the server from creating the necessary streams.  This does not prohibit a server from sending PUSH_PROMISE frames; clients need to reset any promised streams that are not wanted. </del> <ins> Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero prevents the server from opening the streams necessary to push responses. However, this does not prevent the server from reserving streams using PUSH_PROMISE frames, because "reserved" streams do not count toward the concurrent stream limit.  Clients that do not wish to receive pushed resources need to reset any unwanted reserved streams or set SETTINGS_ENABLE_PUSH to 0. </ins> Clients receiving a pushed response MUST validate that either the server is authoritative (see authority) or the proxy that provided
-1 and a NO_ERROR code.  This signals to the client that a shutdown is imminent and that initiating further requests is prohibited. After allowing time for any in-flight stream creation (at least one <del> round-trip time), the server can send another GOAWAY frame with an </del> <ins> round-trip time), the server MAY send another GOAWAY frame with an </ins> updated last stream identifier.  This ensures that a connection can be cleanly shut down without losing requests.
3. <del> For the sake of completeness this is a description of the known use- cases that have been described which would have applicability to the real-time serving of media over QUIC, and MoQ participants should consider which use case(s) should be part of any work, and which can be excluded.  Previously I-D.draft-rtpfolks-quic-rtp-over-quic defined several key use cases, in addition to several others which may be summarised under the following: Peer-to-peer interactive applications, such as telephony or video conferencing.  This may be in a 1-to-1 scenario, or in a multi- party arrangement.  TODO: add more description here. </del> <ins> Previously I-D.draft-rtpfolks-quic-rtp-over-quic defined several key use cases, in addition to several others defined elsewhere.  The two use cases that are most applicable today given the existing and known future capabilities of QUIC include: </ins> Unidirectional live stream contribution.  Two immediate scenarios that best describe this is firstly users on a streaming platform in a remote scenario from their phone live streaming an event or
4. <del> TODO: Fill this in with detail </del> <ins> This section lists requirements for providing real time media streaming over a QUIC connection. 4.1. When initiating a media session, both the sender and receiver should be able to negotiate the codecs, bitrates and other media details based on capabilities and preferences. 4.2. Media should be able to flow in either direction from client to server or vice-versa, either individually or concurrently. 4.3. TODO: Unsure if this should be a requirement.  If it is, 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 our potential requirements. 4.4. The protocol SHOULD have capabilities asides from TLS mutual authentication to allow hosts to authenticate one another, this should be kept simple but robust in nature to prevent attacks like credential brute-forcing. </ins> 5.
Note to Readers Source code and issues for this draft can be found at <del> https://github.com/fiestajetsam/draft-gruessing-moq-requirements [1]. </del> <ins> https://github.com/moq-wg/moq-requirements [1]. </ins> Discussion of this draft should take place on the IETF Media Over QUIC (MoQ) mailing list, at https://www.ietf.org/mailman/listinfo/moq
For instance, a speaker in a conferencing application might make a statement, and then ask, "but what do you folks think?"  If one of the listeners is able to answer in a timeframe that seems natural, <del> without without waiting for the current speaker to explicitly "hand over" control of the conversation, this would qualify as "Interactive". </del> <ins> without waiting for the current speaker to explicitly "hand over" control of the conversation, this would qualify as "Interactive". </ins> Live Streaming use cases allow consumers of media to "watch together", without having a sense that one consumer is experiencing
3.1.3. <del> Where media is both sent and received; This may include audio from both microphone(s) and/or cameras, or may include "screen sharing" or inclusion of other content such as slide, document, or video presentation.  This may be done as client/server, or peer to peer with a many to many relationship of both senders and receivers.  The target for latency may be as large as 200ms or more for some media types such as audio, but other media types in this use case have much more stringent latency targets. </del> <ins> In the Video Conferencing/Telephony use case, media is both sent and received.  This use case typically includes audio and video media, and may also include one or more additional media types, such as "screen sharing" and other content such as slides, documents, or video presentations.  This may be done as client/server, or peer to peer with a many to many relationship of both senders and receivers. The target for latency may be as large as 200ms or more for some media types such as audio, but other media types in this use case have much more stringent latency targets. </ins> 3.2. <del> 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- directionality of conferencing, this should be considered a "hybrid". There can be additional functionality as well that overlap between the two, such as "live rewind", or recording abilities. Another consideration is the limits of "human bandwidth" - as the number of sources are included into a given session increase, the amount of media that can usefully understood by a single person diminishes.  To put it more simply - too many people talking at once is much more difficult to understand than one person speaking at a time, and this varies on the audience and circumstance.  Subsequently this will define some limitations in the number of potential concurrent or semi-concurrent, bidirectional communications that occur. 3.3. </del> The use cases in this section like those in interact do set some expectations to minimise high and/or highly variable latency, however their key difference is that are seldom bi-directional as their basis
advertisement breaks).  The use of "live rewind" where a window of media between the live edge and trailing edge can be made available for clients to playback, either because the local player falls behind <del> edge or because the viewer wishes to play back from a point in the past. </del> <ins> the leading edge or because the viewer wishes to play back from a point in the past. 3.3. 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.  This use case can have an audience as large as Live Media Streaming as described in lmstream, but also relies on the interactivity and bi-directionality of conferencing as in Video Conferencing as described in vidconf.  For this reason, this type of use case can be considered a "hybrid".  There can be additional functionality as well that overlap between the two, such as "live rewind", or recording abilities. Another consideration is the limits of "human bandwidth" - as the number of sources are included into a given session increase, the amount of media that can usefully understood by a single person diminishes.  To put it more simply - too many people talking at once is much more difficult to understand than one person speaking at a time, and this varies on the audience and circumstance.  Subsequently this will define some limitations in the number of potential concurrent or semi-concurrent, bidirectional communications that occur. </ins> 4.
Whilst QUIC and conversely TLS supports the ability for mutual authentication through client and server presenting certificates and performing validation, this is infeasible in many use cases where <del> provisioning of client TLS certificates is unsupported or infeasible. Thus, support for a primitive method of authentication between MoQ entities SHOULD be included to authenticate entities between one another, noting that implementations and deployments should determine which authorisation model if any is applicable. </del> <ins> provisioning of client TLS certificates is unsupported or impractical.  Thus, support for a primitive method of authentication between MoQ entities SHOULD be included to authenticate entities between one another, noting that implementations and deployments should determine which authorisation model if any is applicable. </ins> 4.9.2.
being carried in the other direction, this would not qualify as "Interactive". <ins> 2.2. The MOQ working group has used a wide variety of terms, with some, but not enough, effort to reconcile terms in use in various drafts. As these drafts are being adopted by the MOQ working group, it seems right to make every effort to align terminology for ease of reading and implementation. This draft does not yet, but will, align with the terminology defined in I-D.draft-ietf-moq-transport, as a starting point.  We note that -00 of that draft observes that the working group hasn't converged on terminology and definitions, and if MOQ terminology changes, the terminology in this draft will change accordingly. </ins> 3. Our goal in this section is to understand the range of use cases that
control of packetization and transmission, with addtional support for retransmission as an optional extension. <ins> To provide an overview of interactive use cases, we can consider a conferencing session comprised of: Multiple emitters, publishing on multiple tracks (audio, video tracks and at different qualities) A media switch, sourcing tracks that represent a subset of tracks from across all the emitters.  Such subset may represent tracks representing top 5 speakers at higher qualities and lot of other tracks for rest of the emitters at lower qualities. Multiple receivers, with varied receiving capacity (bandwidth limited), subscribing to subset of the tracks This setup relies on the following functionalities: Media Switches source new tracks but retain the media payload from the original emitters.  This implies publishing new Track IDs sourced from the SFU, with object payload unchanged from the original emitters. Media Switches propagate a subset of tracks as-is from the emitters to the subscribers.  This implies Track IDs to be unchanged between the emitters and the receivers. Subscribers explictly request one or more media tracks in appropriate qualities and dynamically move between the qualtiies during the course of the session. Another topology for the conferencing use-case is to use multiple distribution networks for delivering the media, with media switching functionality running across distribution networks and these media functions as part of the core distribution network as shown below. Such a topology needs to meet all the properties listed in the homogenous topology setup, however having multiple distribution networks, and relying on the distribution networks to carry out the media delivery, brings in further requirements towards a data model that enables tracks to be uniquely identifiable across the distribution networks and not just within a single distribution network. </ins> 3.1.1. In this use case the computation for running a video game (single or
3.2.1. <ins> In a typical live video ingest, the broadcast client - for example, an Open Broadcaster Software (OBS) client, publishes the video content to an ingest server under a provider domain. The Track IDs are scoped to the broadcast for the application under a provider domain. </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
3.2.3. <del> Where media is received from a live broadcast or stream either as a broadcast with fixed duration or as ongoing 24/7 output.  The number of receivers may vary depending on the type of content; breaking news events may see sharp, sudden spikes, whereas sporting and entertainment events may see a more gradual ramp up with a higher sustained peak with some changes based on match breaks or interludes. </del> <ins> In a reference live streaming example shown below, the emitter streams one or more tracks as part of the application operated under a provider domain, which is then distributed to multiple clients using some form of distribution server operating under the same provider domain, over a content distribution network. In this setup, one can visualize the ingest and distribution as two separate systems operating within a given provider domain.  One implication of this organization is that the Track Ids used by the emitter need not match the ones referred to by the subscribers.  This can be the case because the distribution server sources the media as new tracks (for instance, if the media is transcoded after ingest) In Live Media Streaming, media might be received from a live broadcast or stream either as a broadcast with fixed duration or as ongoing 24/7 output.  The number of receivers may vary depending on the type of content; breaking news events may see sharp, sudden spikes, whereas sporting and entertainment events may see a more gradual ramp up with a higher sustained peak with some changes based on match breaks or interludes. </ins> Such broadcasts may comprise of multiple audio or video outputs with different codecs or bitrates, and may also include other types of
4.8.1. <ins> It is possible to use groups as units of congestion control.  When the sending strategy is understoud, the objects in the group can be assigned sequence numbers and drop priorities that capture the encoding dependencies, such that: an object can only have dependencies with other objects in the same group, an object can only have dependencies with other objects with lower sequence numbers, an object can only have dependencies with other objects with lower or equal drop priorities. This simple rules enable real-time congestion control decisions at relays and other nodes.  The main drawback is that if a packet with a given drop priority is actually dropped, all objects with higher sequence numbers and higher or equal drop priorities in the same group must be dropped.  If the group duration is long, this means that the quality of experience may be lowered for a long time after a brief congestion.  If the group duration is short, this can produce a jarring effect in which the quality of experience drops perdiodically at the tail of the group. 4.8.2. </ins> To enable use cases where receivers may wish to address a particular time of media in addition to having the most recently produced media available, both "pull" and "push" of media SHOULD be supported, with
4.9.2. <del> 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 the media without authorization.  Generally, there are three aspects of end-to-end media security: </del> <ins> Much of the early discussion about MOQ security was not entirely coherent.  Some contributors pushed for "end-to-end security", and some contributors pushed for the ability of intermediate nodes to have sufficient visibility into media payloads to accomplish the responsibilities those intermediate nodes were given.  Some contributors may have pushed for both, at various times.  It is worthwhile to clarify what "security" means in a MOQ context. Generally, there are three aspects of media security: </ins> Digital Rights Management, which refers to the authorization of receivers to decode a media stream. Sender-to-Receiver Media Security, which refers to the ability of media senders and receivers to transfer media while protected from <del> authorized intermediates and observers, and </del> <ins> unauthorized intermediates and observers, and </ins> Node-to-node Media Security, which refers to security when authorized intermediaries are needed to transform media into a form acceptable to authorized receivers.  For example, this might refer to a video transcoder between the media sender and receiver. <del> **Note: "Node-to-node" refers to a path segment connecting two MOQ nodes, that makes up part of the end-to-end path between the MOQ sender and ultimate MOQ receiver. </del> <ins> "End-to-end security" describes the use of encryption of one or more media stream(s) over an end-to-end path, to provide confidentiality in the presence of any intermediates or observers and prevent or restrict ability to decrypt that media. "Node-to-node security" refers to the use of encryption of one or more media stream(s) over a path segment connecting two MOQ nodes, that makes up part of the end-to-end path between the MOQ sender and ultimate MOQ receiver, to provide confidentiality in the presence of unauthorized intermediates or observers and prevent or restrict ability to decrypt that media. Many MOQ deployment models rely on intermediate nodes, and these intermediate nodes may have a variety of responsibilities, including, but not limited to, rate adaptation based on media metadata routing media based on the characteristics of the media caching media allowing "watch in-progress broadcasts from the beginning", "instant replay" and "fast forward" transcoding media Some of these responsibilities require authorization to see more media headers and even media payload than others.  The protocol SHOULD allow MOQ intermediate nodes to perform a variety of responsibilities, without having access to media headers and/or media payloads that they do not require to carry out their responsibilities. </ins> Support for encrypted media SHOULD be available in the protocol to support the above use cases, with key exchange and decryption