jiebi/CodeConvo huggingface dataset:
Code change:
Following from discussions in , this PR allows a given publishers to un-announce a track namespace to indicate that it is not longer accepting new subscribe requests. The high-level call flow for happy path is as below
Individual Review

Related discussion:
text: 6.9. <ins> The publisher sends the "UNANNOUNCE" control message to indicate its intent to stop serving new subscriptions for tracks within the provided Track Namespace. Track Namespace: Identifies a track's namespace as defined in (track-name). 6.10. </ins> The server sends a "GOAWAY" message to force the client to reconnect. This is useful for server maintenance or reassignments without severing the QUIC connection.  The server can be a producer or a
Code change:
Following from discussions in , this PR allows a given publishers to un-announce a track namespace to indicate that it is not longer accepting new subscribe requests. The high-level call flow for happy path is as below
Individual Review

Related discussion:
text: SHOULD remain connected on both connections for a short period, processing objects from both in parallel. <ins> 6.11. The Track Request Parameters identify properties of the track requested in either the ANNOUNCE or SUSBCRIBE REQUEST control messages.  The peers MUST close the connection if there are duplicates.  The Parameter Value Length field indicates the length of the Parameter Value. The format of "Track Request Parameter" is as follows: 6.11.1. The GROUP SEQUENCE parameter (key 0x00) identifies the group within the track to start delivering objects.  The publisher MUST start delivering the objects from the most recent group, when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.11.2. The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects.  The "GROUP SEQUENCE" parameter MUST be set to identify the group under which to start delivery.  The publisher MUST start delivering from the beginning of the selected group when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.11.3. AUTHORIZATION INFO parameter (key 0x02) identifies track's authorization information.  This parameter is populated for cases where the authorization is required at the track level.  This parameter is applicable in SUBSCRIBE REQUEST and ANNOUNCE messages. </ins> 7. TODO: Expand this section.
Code change:
Following from discussions in , this PR allows a given publishers to un-announce a track namespace to indicate that it is not longer accepting new subscribe requests. The high-level call flow for happy path is as below
Individual Review

Related discussion:
text: 8. <del> TODO: fill out currently missing registries: * MOQT version numbers * SETUP parameters * Track Request parameters * Subscribe Error codes * Announce Error codes * Track format numbers * Message types * Object headers </del> <ins> TODO: fill out currently missing registries: MOQT version numbers SETUP parameters Track Request parameters Subscribe Error codes Announce Error codes Track format numbers Message types Object headers </ins> TODO: register the URI scheme and the ALPN
Code change:
Can we PLEASE number editor's drafts as draft-ietf-moq-transport-latest? Currently, it says draft-00, which can result is significant confustion with respect to the last published draft and creates an unstable interop target.
+1 this shouldn't have been checked in.

Related discussion:
text: Media over QUIC Transport <del> draft-ietf-moq-transport-00 </del> <ins> draft-ietf-moq-transport-latest </ins> Abstract
Code change:
and . There was consensus in Cambridge that removing the special meaning of zero length gets rid of difficult code, removes potental foot guns, saves a byte, and enables actual zero length payloads, which supposedly has use cases.
Since message (6. Messages) will be the main piece of info of MOQ I think we should try to minimize its size. Assuming most of the messages send to the wire will be objects inside a quic stream, the length should be NOT needed. Could we use 1 bit in "type" to indicate if length is present, we could save some bytes without overcomplicating the protocol
The length of a QUIC stream is only known after the FIN bit is received(ie the end of QUIC stream). Putting the length in the message header can ensure the size of stream is known at the beginning of the stream.
The size of an OBJECT is a varint so that's a single byte when 0. Even in the situation where you're sending an OBJECT per frame, that's what like 100 OBJECTs per second?. That's 100B/s while the media might average 375,000B/s (3Mb/s). But yeah, we can optimize when the draft is closer to completion and things are more concrete. I like how QUIC STREAM frames are encoded, where the frame type indicates if fields are present (ex. length).
This issue is related to the question of what types of lengths we'll support, and whether we'll support those that go to the end of a quic stream (aka infinite length). "unknown" payloads where they're a delimiter of some sort had no support, because you have to do extra parsing. This issue is about two types: Object and Object + Length, which has support from the WG. Martin to roll into PR
From Cambridge: Martin will put this in a separate PR once lands

Related discussion:
text: A OBJECT message contains a range of contiguous bytes from from the specified track, as well as associated metadata required to deliver, <del> cache, and forward it. </del> <ins> cache, and forward it.  There are two subtypes of this message.  When the message type is 0x00, the optional Object Payload Length field is present.  When the message type ix 0x02, the field is not present. </ins> The format of the OBJECT message is as follows:
Code change:
and . There was consensus in Cambridge that removing the special meaning of zero length gets rid of difficult code, removes potental foot guns, saves a byte, and enables actual zero length payloads, which supposedly has use cases.
Since message (6. Messages) will be the main piece of info of MOQ I think we should try to minimize its size. Assuming most of the messages send to the wire will be objects inside a quic stream, the length should be NOT needed. Could we use 1 bit in "type" to indicate if length is present, we could save some bytes without overcomplicating the protocol
The length of a QUIC stream is only known after the FIN bit is received(ie the end of QUIC stream). Putting the length in the message header can ensure the size of stream is known at the beginning of the stream.
The size of an OBJECT is a varint so that's a single byte when 0. Even in the situation where you're sending an OBJECT per frame, that's what like 100 OBJECTs per second?. That's 100B/s while the media might average 375,000B/s (3Mb/s). But yeah, we can optimize when the draft is closer to completion and things are more concrete. I like how QUIC STREAM frames are encoded, where the frame type indicates if fields are present (ex. length).
This issue is related to the question of what types of lengths we'll support, and whether we'll support those that go to the end of a quic stream (aka infinite length). "unknown" payloads where they're a delimiter of some sort had no support, because you have to do extra parsing. This issue is about two types: Object and Object + Length, which has support from the WG. Martin to roll into PR
From Cambridge: Martin will put this in a separate PR once lands

Related discussion:
text: send-order or priority ordering-by-priorities value. Object Payload Length: The length of the following Object Payload. <del> The sender MAY encode a zero in this field, which means that the message continues to the end of the stream. </del> <ins> If this field is absent, the object payload continues to the end of the stream. </ins> Object Payload: An opaque payload intended for the consumer and SHOULD NOT be processed by a relay.
Code change:
one question is if they come on different streams can they get out order
My inclination is to send a SubscriptionEnd {} message with appropriate Reason Code set. This will help to support the case that we discussed on publisher wanting to indicate wanting to stop publishing
SUBSCRIPTIONEND and SUBSCRIPTIONEND_ERROR could be split for the graceful vs non-graceful cases.
Discussion in room seems to be rather not have an error after OK but instead use new messages or in subscribe_end message
I'd like to consolidate messages at some point, but we can revisit later.

Related discussion:
text: The subscriber making the subscribe request is notified of the result of the subscription, via "SUBSCRIBE OK" (message-subscribe-ok) or the <del> "SUBSCRIBE ERROR" message-subscribe-error control message. </del> <ins> "SUBSCRIBE ERROR" message-subscribe-error control message.  The entity receiving the SUBSCRIBE MUST send only a single response to a given SUBSCRIBE of either an OK or ERROR. </ins> For successful subscriptions, the publisher maintains a list of subscribers for each full track name.  Each new OBJECT belonging to
Code change:
one question is if they come on different streams can they get out order
My inclination is to send a SubscriptionEnd {} message with appropriate Reason Code set. This will help to support the case that we discussed on publisher wanting to indicate wanting to stop publishing
SUBSCRIPTIONEND and SUBSCRIPTIONEND_ERROR could be split for the graceful vs non-graceful cases.
Discussion in room seems to be rather not have an error after OK but instead use new messages or in subscribe_end message
I'd like to consolidate messages at some point, but we can revisit later.

Related discussion:
text: specific (typically based on prior business agreement). Relays respond with "ANNOUNCE OK" and/or "ANNOUNCE ERROR" control <del> messages providing the results of announcement. </del> <ins> messages providing the results of announcement.  The entity receiving the ANNOUNCE MUST send only a single response to a given ANNOUNCE of either an OK or ERROR. </ins> OBJECT message header carry short hop-by-hop Track Id that maps to the Full Track Name (see message-subscribe-ok).  Relays use the Track
Code change:
Also, can someone explain what the following paragraph is saying, because I'm having a difficult time parsing it.
The next paragraph is trying to say that if you receive HoL blocked stream data at a relay you should try to forward what you have. The goal is to mitigate accumulating latency at every relay hop. I think this makes sense in two cases: You receive data that you know to be within an object you have already seen the header for. Eg: the object length is 100 and you miss bytes 0-49 but get 50-99, you can forward 50-99, as long as your QUIC library supports out of order reads and writes to a stream (not many presently do). This also applies when the object has no length and occupies the entire stream. You are missing some object data for object N on a stream, but you receive the header for object N + 1. This is (potentially) less problematic since the relay might be able to open a new stream to forward it, so out-of-order stream write APIs are not required. In any case, the text probably needs clarification, and perhaps moving from SHOULD (but we know you won't) to MAY is warranted?
Should we mention that a relay should start sending object as soon as the object can be identified (after the header)? Since the draft points out latency as a big deal, it seems this is a must have if we want to cover ULL cases
+1.
It used to be in but was removed. The text was pretty simple: I think and the agreement was to put it into some non-existent latency section.
+1 We should add a recommendation text for Relays to address the request from NAME
sooner is better I do think this might be interpreted by some people in an over zealous sort of way ( like turning off nagle type things ). I do wonder about just using MAY. But happy either way. SHOULD and MAY mean the same thing.

Related discussion:
text: prioritize streams (priority-congestion) based on the send order/ priority. <ins> A sender SHOULD begin sending incomplete objects when available to avoid incurring additional latency. </ins> A relay that reads from a stream and writes to stream in order will introduce head-of-line blocking.  Packet loss will cause stream data to be buffered in the QUIC library, awaiting in order delivery, which
Code change:
Issue raised at interim on Feb 1, 2023: Does the protocol need to define a failover if QUIC is not available on a specific path. If so, is it the same failover in all cases?
Note that WebTransport does provide a failover to HTTP/2.
We need a answer for Raw QUIC too
We discussed this in chartering and came down on a hard no. It just makes things too complicated. Yep, the webtransport version of it might work fine on TCP and we are not out to break that but it is not a design goal. This is about media over QUIC and QUIC is over UDP. The CDNs may internally do whatever they do but that is a black box.
I agree that this is out of scope, based on my reading of the charter, which says "can be used over raw QUIC or WebTransport." I would like to either close with no action or we can add editorial text that notes that all paths may not support QUIC.
It was decided that a sentence or two about this, including a note that the appropriate fallback may be something entirely different from MoQ (ie: DASH/HLS/etc) depending upon the application and deployment.

Related discussion:
text: WebTransport.  Both provide streams and datagrams with similar semantics (see I-D.ietf-webtrans-overview); thus, the main difference lies in how the servers are identified and how the connection is <del> established. </del> <ins> established.  There is no definition of the protocol over other transports, such as TCP, and applicaitons using MoQ might need to fallback to another protocol when QUIC or WebTransport aren't available. </ins> 3.1.1.
Code change:
Given this also runs over WebTransport, it's best to avoid QUIC unless it's specifically referring to the transport.
Though MOQT is optimized for QUIC, it technically can go over WebTransport over HTTP/1 or HTTP/2. There are a number of cases when QUIC is used when it could be something else and in most cases, specifying QUIC is not critical to the design. For example "Consumer: A QUIC endpoint receiving media over the network." Also, the definitions in 1.2 frequently reference terms defined later in the list.
Absolutely. Stream prioritization and congestion control is better with QUIC, and thus can support lower latencies, but MoQ over TCP should still work well enough.
For what its worth, we did did say during chartering that were were not going to focus on solving any of the problems that happen with fallback to TCP. Clearly we are not going to go and brak whatever fallback WebTransport does, but they key thing is this work when then WebTransport is over QUIC, not other cases
I completely agree. This is an editorial point that there are times when 'QUIC' is used when it may not actually be QUIC. In many cases, just removing that word makes the sentence both slightly more accurate and shorter.

Related discussion:
text: Abstract This document defines the core behavior for Media over QUIC Transport <del> (MOQT), a media transport protocol over QUIC.  MOQT allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints.  It supports intermediate content distribution networks and is designed for high scale and low latency distribution. </del> <ins> (MOQT), a media transport protocol designed to operate over QUIC and WebTransport, which have similar functionality.  MOQT allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints.  It supports intermediate content distribution networks and is designed for high scale and low latency distribution. </ins> 1. <del> Media Over QUIC Transport (MOQT) is a transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport, for the dissemination of media.  MOQT utilizes a publish/subscribe workflow in which producers of media publish data in response to subscription requests from a multiplicity of endpoints.  MOQT supports wide range of use-cases with different </del> <ins> Media Over QUIC Transport (MOQT) is a protocol that is optimized for the QUIC protocol QUIC, either directly or via WebTransport WebTransport, for the dissemination of media.  MOQT utilizes a publish/subscribe workflow in which producers of media publish data in response to subscription requests from a multiplicity of endpoints.  MOQT supports wide range of use-cases with different </ins> resiliency and latency (live, interactive) needs without compromising the scalability and cost effectiveness associated with content delivery networks.
Code change:
Given this also runs over WebTransport, it's best to avoid QUIC unless it's specifically referring to the transport.
Though MOQT is optimized for QUIC, it technically can go over WebTransport over HTTP/1 or HTTP/2. There are a number of cases when QUIC is used when it could be something else and in most cases, specifying QUIC is not critical to the design. For example "Consumer: A QUIC endpoint receiving media over the network." Also, the definitions in 1.2 frequently reference terms defined later in the list.
Absolutely. Stream prioritization and congestion control is better with QUIC, and thus can support lower latencies, but MoQ over TCP should still work well enough.
For what its worth, we did did say during chartering that were were not going to focus on solving any of the problems that happen with fallback to TCP. Clearly we are not going to go and brak whatever fallback WebTransport does, but they key thing is this work when then WebTransport is over QUIC, not other cases
I completely agree. This is an editorial point that there are times when 'QUIC' is used when it may not actually be QUIC. In many cases, just removing that word makes the sentence both slightly more accurate and shorter.

Related discussion:
text: other uses of bidirectional streams, a peer MAY currently close the connection if it receives a second bidirectional stream. <del> The control stream MUST NOT be abruptly closed at the QUIC layer. Doing so results in the session being closed as a 'Protocol Violation'. </del> <ins> The control stream MUST NOT be abruptly closed at the underlying transport layer.  Doing so results in the session being closed as a 'Protocol Violation'. </ins> 3.3. <del> QUIC streams aside from the control stream MAY be canceled due to </del> <ins> Streams aside from the control stream MAY be canceled due to </ins> congestion or other reasons by either the sender or receiver.  Early <del> termination of a QUIC stream does not affect the MoQ application state, and therefore has no effect on outstanding subscriptions. </del> <ins> termination of a stream does not affect the MoQ application state, and therefore has no effect on outstanding subscriptions. </ins> 3.4.
Code change:
Given this also runs over WebTransport, it's best to avoid QUIC unless it's specifically referring to the transport.
Though MOQT is optimized for QUIC, it technically can go over WebTransport over HTTP/1 or HTTP/2. There are a number of cases when QUIC is used when it could be something else and in most cases, specifying QUIC is not critical to the design. For example "Consumer: A QUIC endpoint receiving media over the network." Also, the definitions in 1.2 frequently reference terms defined later in the list.
Absolutely. Stream prioritization and congestion control is better with QUIC, and thus can support lower latencies, but MoQ over TCP should still work well enough.
For what its worth, we did did say during chartering that were were not going to focus on solving any of the problems that happen with fallback to TCP. Clearly we are not going to go and brak whatever fallback WebTransport does, but they key thing is this work when then WebTransport is over QUIC, not other cases
I completely agree. This is an editorial point that there are times when 'QUIC' is used when it may not actually be QUIC. In many cases, just removing that word makes the sentence both slightly more accurate and shorter.

Related discussion:
text: object are still delivered in order; this send order only applies to the ordering between objects. <del> A sender MUST send each object over a dedicated QUIC stream.  The QUIC library should support prioritization (priority-congestion) such that streams are transmitted in send order. </del> <ins> A sender MUST send each object over a dedicated stream.  The library should support prioritization (priority-congestion) such that streams are transmitted in send order. </ins> A receiver MUST NOT assume that objects will be received in send order, for the following reasons:
Code change:
Given this also runs over WebTransport, it's best to avoid QUIC unless it's specifically referring to the transport.
Though MOQT is optimized for QUIC, it technically can go over WebTransport over HTTP/1 or HTTP/2. There are a number of cases when QUIC is used when it could be something else and in most cases, specifying QUIC is not critical to the design. For example "Consumer: A QUIC endpoint receiving media over the network." Also, the definitions in 1.2 frequently reference terms defined later in the list.
Absolutely. Stream prioritization and congestion control is better with QUIC, and thus can support lower latencies, but MoQ over TCP should still work well enough.
For what its worth, we did did say during chartering that were were not going to focus on solving any of the problems that happen with fallback to TCP. Clearly we are not going to go and brak whatever fallback WebTransport does, but they key thing is this work when then WebTransport is over QUIC, not other cases
I completely agree. This is an editorial point that there are times when 'QUIC' is used when it may not actually be QUIC. In many cases, just removing that word makes the sentence both slightly more accurate and shorter.

Related discussion:
text: Packet loss or flow control can delay the send of individual streams. <del> The sender might not support QUIC stream prioritization. </del> <ins> The sender might not support stream prioritization. </ins> TODO: Refer to Congestion Response and Prioritization Section for further details on various proposals.