jiebi/CodeConvo huggingface dataset:
Change:
in Section 2 "Flow Identifiers" it reads this to me seems to be in conflict with the opening statement if the flow-id is in the DATAGRAM payload, the transport is not supposed to be peeking at it. While it could be a nice (but a bit hacky) optimization in a real-world implementation, I feel like the RFC having it as a SHOULD is not ideal.
In my experience, in order to build a high performance implementation of QUIC, you have to leverage the fact that layers can share information to improve performance. Are you saying that you'd prefer not using SHOULD for this kind of optimization?
I think Luca might have a point. If we consider this as a feature that a transport provides as a service, I don't really know what the service provides. There isn't another transport mechanism that relies on the ordering, or an interoperable aspect (would the other side be able to detect this?). It seems this is an aspect more about the API that QUIC provides, which is going to be a rich field of opportunity. There could be benefits but I don't know if we need to use the SHOULD. We could probably relax the language and try to articulate the benefits or tradeoffs of packetization and frame bundling. For instance, batching might interfere with timeliness, and controlling that might start creeping into prioritisation territory. The more I think about it, the described behaviour about batch processing might assume the receiver behaves a certain way, which might not be true. Therefore this might not be a good default to recommend.
Fair enough. Perhaps we remove this for now, and add guidance once we have more implementation/deployment experience?
I can live with a less drastic edit, leaving the text in draws the reader attention to the idea that packing could be important. I'd be happy to put together an editorial replacement for review, and if we hate it, then drop the concrete recommendation?
Thanks Lucas, you framed it way better than I could. Also I believe that whether shared-fate within a flow is desirable or not may depend on the application.
I came here looking for the same information: Why is fate-sharing desired? Is there some background to this?
I think more implementation and deployment experience would help here. I can see cases like tunneling IP flows containing TCP where fate sharing is preferable, since it's better to lose two adjacent packets in one flow than one packet each in two flows. But it seems a bit use-case specific? Also, you would expect most TCP segments to be large enough you couldn't put two into a single QUIC packet.

Discussion:
Flows lack any of the ordering or reliability guarantees of streams. Beyond this, a sender SHOULD ensure that DATAGRAM frames within a <del> single flow are transmitted in order relative to one another.  If multiple DATAGRAM frames can be packed into a single QUIC packet, the sender SHOULD group them by flow to promote fate-sharing within a specific flow and improve the ability to process batches of datagram messages efficiently on the receiver. </del> <ins> single flow are transmitted in order relative to one another. </ins> 3.
Change:
Currently, the Datagram-Flow-Id Header Field Definition section contains examples of the Datagram-Flow-Id header, which includes a 4-flow mechanism for conveying ECN information: This example seems to be tripping people up, myself included, by attempting to solve a problem of in-band signaling of non-UDP-payload bits by providing these streams, and drawing attention to that problem rather than the capability being described. I propose we remove this example until we have a better one to replace it. If we cannot find a good example, that also lends some evidence that perhaps we don't need the feature of creating multiple Datagram-Flow-Id associations in the same request.

Discussion:
wishes to use four datagram flows for the lifetime of its request stream could look like this: <del> In this example, 42 is the unnamed flow, 44 represents the name "ecn- ect0", 46 represents "ecn-ect1", and 48 represents "ecn-ce".  Note that, since the list ordering does not carry semantics, this example can be equivalently encoded as: </del> <ins> In this example, 42 is the unnamed flow, 44 represents the name "foo", 46 represents "bar", and 48 represents "baz".  Note that, since the list ordering does not carry semantics, this example can be equivalently encoded as: </ins> Even if a sender attempts to communicate the meaning of a flow before it uses it in an HTTP/3 datagram, it is possible that its peer will
Change:
URL it clear what the spec is allowing, we should make a note in Section 4.4 that the ordering/buffering requirements of DATGRAM frames and register capsules (from sec 3) do not apply to intermediaries when forwarding. That's tangential to Luca's OP so we can spin it off separately. Originally posted by NAME in URL

Discussion:
Endpoints MUST NOT send DATAGRAM frames using a Context ID until they have either sent or received a REGISTER_DATAGRAM_CONTEXT Capsule with <del> the same Context ID.  However, due to reordering, an endpoint that receives a DATAGRAM frame with an unknown Context ID MUST NOT treat it as an error, it SHALL instead drop the DATAGRAM frame silently, or buffer it temporarily while awaiting the corresponding REGISTER_DATAGRAM_CONTEXT Capsule. </del> <ins> the same Context ID.  However, reordering can cause DATAGRAM frames to be received with an unknown Context ID.  Receipt of such frames MUST NOT be treated as an error.  Endpoints SHALL drop the DATAGRAM frame silently, or buffer it temporarily while awaiting the corresponding REGISTER_DATAGRAM_CONTEXT Capsule.  Intermediaries SHALL drop the DATAGRAM frame silently, MAY buffer it, or forward it on immediately. </ins> Endpoints MUST NOT register the same Context ID twice on the same stream.  This also applies to Context IDs that have been closed using
Change:
It doesn't appear that the peer has any say in the allocation of context IDs. If not, they're not really "negotiated." Perhaps better to say that they are "declared" or merge with "allocated."

Discussion:
the datagram: the context identifier then maps to a compression context that the receiver can use to reconstruct the elided data. <del> Contexts are optional, their use is negotiated on each request stream using registration capsules, see register-capsule and register-no- context-capsule.  When contexts are used, they are identified within the scope of a given request by a numeric value, referred to as the context ID.  A context ID is a 62-bit integer (0 to 2^62-1). </del> <ins> Contexts are optional, whether to use them or not is decided by the client on each request stream using registration capsules, see register-capsule and register-no-context-capsule.  When contexts are used, they are identified within the scope of a given request by a numeric value, referred to as the context ID.  A context ID is a 62-bit integer (0 to 2^62-1). </ins> While stream IDs are a per-hop concept, context IDs are an end-to-end concept.  In other words, if a datagram travels through one or more

receives a QUIC DATAGRAM frame whose payload is too short to allow parsing the Quarter Stream ID field, the intermediary MUST treat it as an HTTP/3 connection error of type H3_GENERAL_PROTOCOL_ERROR.  The <del> Context ID field is optional and its use is negotiated end-to-end, see register-no-context-capsule.  Therefore intermediaries cannot know whether the Context ID field is present or absent and they MUST ignore any HTTP/3 Datagram fields after the Quarter Stream ID. </del> <ins> Context ID field is optional and whether it is present or not is decided end-to-end by the client, see register-no-context-capsule. Therefore intermediaries cannot know whether the Context ID field is present or absent and they MUST ignore any HTTP/3 Datagram fields after the Quarter Stream ID. </ins> Endpoints parse both the Quarter Stream ID field and the Context ID field in order to associate the QUIC DATAGRAM frame with a stream and

MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. <del> Extensions MAY define a different mechanism to negotiate the presence of contexts, and they MAY do so in a way which is opaque to </del> <ins> Extensions MAY define a different mechanism to communicate whether contexts are in use, and they MAY do so in a way which is opaque to </ins> intermediaries. 4.4.3.
Change:
The thing that sucks here is that the diagram won't auto expand , so we can't easily ref the section. Manually referring to the section is a maintenance pain. So instead just state the actual type in the text an the diagram. I have a feeling you were linking to the section to avoid the maintenance hassle of updating type codes in multiple place. But I'm quite happy to take that burden because I find it more pleasant to read this way.
Perfectly reasonable
QUIC and HTTP/3 style is to define the general format and then in each instance define the object including all of its fields. This would look like This can later be updated with the actual type value once things settle down
Fine by me.
There's a disparity between the largest flow ID that can be carried in the DATAGRAM frame and the largest that we can express in Datagram-Flow-Id. Draft 00 prevents a flow ID allocation of >= 10^15-1 but doesn't seem to address the case where a DATAGRAM frame contains that value. This is clearly an error, and I'd suggest that it is a connection error; probably or some new codepoint if we really wanted.
I don't think that needs to be an error, we can simply treat this like any other unknown flow ID?
IMO this is clearly a situation that shouldn't happen and indicates the sending endpoint probably has some bug. I'm not sure on what being silent on the matter helps.
This issue is no longer relevant now that we have merged , closing.

Discussion:
The REGISTER_DATAGRAM_CONTEXT capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer of the encoding and semantics of datagrams associated with a given context <del> ID.  Its Capsule Data field consists of: </del> <ins> ID. </ins> The context ID to register.

value of the capsule type) allows a client to inform the server that datagram contexts will not be used with this stream.  It also informs the server of the encoding and semantics of datagrams associated with <del> this stream.  Its Capsule Data field consists of: </del> <ins> this stream. </ins> A variable-length integer that defines the semantics and encoding of the HTTP Datagram Payload field of datagrams, see datagram-

The CLOSE_DATAGRAM_CONTEXT capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer that it will no longer send or parse received datagrams associated with a given <del> context ID.  Its Capsule Data field consists of: </del> <ins> context ID. </ins> The context ID to close.

The DATAGRAM capsule (see iana-types for the value of the capsule type) allows an endpoint to send a datagram frame over an HTTP stream.  This is particularly useful when using a version of HTTP <del> that does not support QUIC DATAGRAM frames.  Its Capsule Data field consists of: </del> <ins> that does not support QUIC DATAGRAM frames. </ins> A variable-length integer indicating the context ID of the datagram (see datagram-contexts).  Whether or not this field is
Change:
err'ing on the side of succinct
There's now several different concepts to wrangle in this document. Reading from the top, we first tackle multiplexing (the major motivation for the document), then the frame, then capsules. Capsules underpin the mechanics of multiplexing. I don't think we can fix this chicken and egg problem but adding a brief overview of the concepts and terms before they are tackled in the prose could help readability.
I think that sounds like a great idea!
Thanks for doing this!

Discussion:
demultiplexing layer.  Additionally, this document defines how to convey datagrams over prior versions of HTTP. <ins> This document is structured as follows: multiplexing presents core concepts for multiplexing across HTTP versions. datagram-contexts defines datagram contexts, an optional end- to-end multiplexing concept scoped to each HTTP request. datagram-formats defines datagram formats, which are scoped to contexts.  Formats communicate the format and encoding of datagrams sent using the associated context. Contexts are identified using a variable-length integer. Requirements for allocating identifier values are detailed in context-id-alloc. format defines how QUIC DATAGRAM frames are used with HTTP/3. setting defines an HTTP/3 setting that endpoints can use to advertise support of the frame. capsule introduces the Capsule Protocol and the "data stream" concept.  Data streams are initiated using special-purpose HTTP requests, after which Capsules, an end-to-end message, can be sent. The following Capsule types are defined, together with guidance for defining new types: REGISTER_DATAGRAM_CONTEXT REGISTER_DATAGRAM_NO_CONTEXT CLOSE_DATAGRAM_CONTEXT DATAGRAM </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Change:
…king hte law Also, switch to format to beatuiful superscript HTML rendering as used by RFC 9000.
Stating the obvious here. But we're using value with a legal range larger than semantically legal. RFC 9000 has some similar caveats with MAX_STREAMS URL To address this, the suggestion is to add something like
That suggestion sounds good to me.

Discussion:
register-capsule and register-no-context-capsule.  When contexts are used, they are identified within the scope of a given request by a numeric value, referred to as the context ID.  A context ID is a <del> 62-bit integer (0 to 2^62-1). </del> <ins> 62-bit integer (0 to 2 -1). </ins> While stream IDs are a per-hop concept, context IDs are an end-to-end concept.  In other words, if a datagram travels through one or more

A variable-length integer that contains the value of the client- initiated bidirectional stream that this datagram is associated <del> with, divided by four.  (The division by four stems from the fact </del> <ins> with, divided by four (the division by four stems from the fact </ins> that HTTP requests are sent on client-initiated bidirectional <del> streams, and those have stream IDs that are divisible by four.) </del> <ins> streams, and those have stream IDs that are divisible by four). The largest legal QUIC stream ID value is 2 -1, so the largest legal value of Quarter Stream ID is 2 -1 / 4.  Receipt of a frame that includes a larger value MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </ins> A variable-length integer indicating the context ID of the datagram (see datagram-contexts).  Whether or not this field is
Change:
From NAME " reliable media using HTTP over TCP," should MOQ be cited here ? or HTTP/3 over QUIC ?
NAME - Thanks for catching this. The relevant point here is that HTTP is carried over reliable transport protocols. The behavior of specific transport protocols is described in subsections of Section 6. I've clarified that in Section 2.

Discussion:
consider the effects of network design decisions on application-level performance, with considerations for the impact on video delivery. <del> Much of the focus of this document is on reliable media using HTTP over TCP, which is widely used because </del> <ins> Much of the focus of this document is on reliable media using HTTP. HTTP is widely used because </ins> support for HTTP is widely available in a wide range of operating systems,

HTTP can make use of already-deployed caching infrastructure. <ins> Various HTTP versions have been used for media delivery.  HTTP/1.0, HTTP/1.1 and HTTP/2 are carried over TCP, and TCP's transport behavior is described in tcp-behavior.  HTTP/3 is carried over QUIC, and QUIC's transport behavior is described in quic-behavior. </ins> Unreliable media delivery using RTP and other UDP-based protocols is also discussed in ultralow, udp-behavior, and hop-by-hop-encrypt, but it is difficult to give general guidance for these applications.  For
Change:
From NAME Unsure whether the end part of this section is relevant to the document as it is rather anecdotical.
We should explain the impact on the Internet, the IETF, and regulatory agencies from the BitTorrent experience.
Working session discussion: yes this is anecdotal, but is a worthwhile example to keep because it adds a concrete example to the abstract notion of unpredictable traffic and its impacts. We think the right response is to add a paragraph to this anecdote explaining the ultimate impact to the internet that this example of unpredictable traffic had as a conclusion to explain how the experiences from unpredictable traffic can cause large and sudden shifts in network operational practice.
NAME - I agree. I suspect that the number of people who remember the impact of Comcast attending to "manage" BitTorrent on residential networks is declining every year, but it was horrendous at the time. We should make it clear that you don't have to have a hurricane to end up with sudden and massive spikes in network traffic that you never planned for.
I teach this every year to keep the new generation aware of some of the non-sense stuff their elder brothers (or sisters) had to put up with. It was not just Comcast, I can name 5 other names based on my own testing at that time.
I like the last paragraph of the PR ;-) Thanks
LGTM

Discussion:
internet service provider (ISP) to attempt to "throttle" these transfers in order to to mitigate the load that these hosts placed on their network.  These efforts were met by increased use of encryption <del> in Bittorrent, similar to an arms race, and set off discussions about "Net Neutrality" and calls for regulatory action. </del> <ins> in Bittorrent, and complaints to regulators calling for regulatory action. The BitTorrent case study is just one example, but the example is included here to make it clear that unpredicted and unpredictable massive traffic spikes may not be the result of natural disasters, but they can still have significant impacts. </ins> Especially as end users increase use of video-based social networking applications, it will be helpful for access network providers to
Change:
From NAME Based on the title it is unclear whether this section also covers "app layer encryption", I guess no but this should be made clear (perhaps high in section 7 by stating that this doc does not cover app layer encryption).
This paragraph appears later in the document - I can move this up under the bullet points and make that clearer.
Fixed as in my previous comment.
BTW, unsure how the authors want me to mark "I have read the change and I like it" ? Currently, simply using a "thum up" emoticon on the solution comment. Let me know if you prefer another marking.
NAME If I can't hear you either giggling or screaming all the way to Texas, and I see a "thumbs up" emoticon, that's clear enough to me!
LGTM

Discussion:
forwarding re-encrypted media content (in this document referred to as "hop-by-hop media encryption"). <del> Both "hop-by-hop" and "end-to-end" encrypted transport may carry media that is, in addition, encrypted at the application layer. </del> <ins> In this document, we will focus on media encrypted at the transport layer, whether encrypted "hop-by-hop" or "end-to-end".  Because media encrypted at the application layer will only be processed by application-level entities, this encryption does not have transport- layer implications.  Of course, both "hop-by-hop" and "end-to-end" encrypted transport may carry media that is, in addition, encrypted at the application layer. </ins> Each of these encryption strategies is intended to achieve a different goal.  For instance, application-level encryption may be

This document does not take a position on whether those goals are "valid" (whatever that might mean). <del> In this document, we will focus on media encrypted at the transport layer, whether encrypted "hop-by-hop" or "end-to-end".  Because media encrypted at the application layer will only be processed by application-level entities, this encryption does not have transport- layer implications. </del> Both "End-to-End" and "Hop-by-Hop" media encryption have specific implications for streaming operators.  These are described in hop-by- hop-encrypt and e2em-encrypt.
Change:
From NAME Authors may also want to refer to drafts about the same considerations (i.e., end-to-end crypto hindering operations).
Agree, will reference (was draft-ietf-tsvwg-transport-encrypt) Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols

Discussion:
dependent on interactions between the congestion controllers in use for TCP-based HTTP traffic and UDP-based HTTP/3 traffic. <del> More broadly, I-D.ietf-quic-manageability discusses manageability of the QUIC transport protocol, focusing on the implications of QUIC's design and wire image on network operations involving QUIC traffic. It discusses what network operators can consider in some detail. </del> 7. "Encrypted Media" has at least three meanings:

these reasons, HTTP/3 is significantly more "opaque" than HTTPS with HTTP/1 or HTTP/2. <ins> I-D.ietf-quic-manageability discusses manageability of the QUIC transport protocol that is used to encapsulate HTTP/3, focusing on the implications of QUIC's design and wire image on network operations involving QUIC traffic.  It discusses what network operators can consider in some detail. More broadly, RFC 9065 RFC9065, "Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols" describes the impact of increased encryption of transport headers in general terms. </ins> 7.2. Although the IETF has put considerable emphasis on end-to-end
Change:
…seemed more well covered in 8824 than in 8825.)
IGTM!
From NAME Last paragraph, while I understand why some mobile providers wants "to lower quality" it would be easier for the reader to understand if the text said "in order to reduce the bandwidth on expensive links, some operators want to lower the quality".
Describe how editing manifests lowers the bandwidth requirements.

Discussion:
also provides both hop-by-hop and end-to-end security guarantees, but can be used with other transport protocols beyond SRTP. <del> If a content provider chooses not to involve intermediaries, this choice should be carefully considered.  As an example, if media manifests are encrypted end-to-end, network providers who had been able to lower offered quality and reduce on their networks will no longer be able to do that.  Some resources that might inform this consideration are in RFC8825 (for WebRTC) and I-D.ietf-quic- </del> <ins> The choice of whether to involve intermediaries sometimes requires careful consideration.  As an example, when ABR manifests were commonly sent unencrypted some networks would modify manifests during peak hours by removing high-bitrate renditions in order to prevent players from choosing those renditions, thus reducing the overall bandwidth consumed for delivering these media streams and thereby improving the network load and the user experience for their customers.  Now that ubiquitous encryption typically prevents this kind of modification, in order to maintain the same level of network health and user experience across networks whose users would have benefitted from this intervention a media streaming operator sometimes needs to choose between adding intermediaries who are authorized to change the manifests or adding significant extra complexity to their service. Some resources that might inform other similar considerations are further discussed in RFC8824 (for WebRTC) and I-D.ietf-quic- </ins> manageability (for HTTP/3 and QUIC). 7.3.